- Linux-stable-mirror - lists.linaro.org

[PATCH] dm crypt: defer the decryption to a tasklet, when being called with interrupts disabled

by Ignat Korchagin

On some specific hardware on early boot we occasionally get [ 1193.920255][ T0] BUG: sleeping function called from invalid context at mm/mempool.c:381 [ 1193.936616][ T0] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/69 [ 1193.953233][ T0] no locks held by swapper/69/0. [ 1193.965871][ T0] irq event stamp: 575062 [ 1193.977724][ T0] hardirqs last enabled at (575061): [<ffffffffab73f662>] tick_nohz_idle_exit+0xe2/0x3e0 [ 1194.002762][ T0] hardirqs last disabled at (575062): [<ffffffffab74e8af>] flush_smp_call_function_from_idle+0x4f/0x80 [ 1194.029035][ T0] softirqs last enabled at (575050): [<ffffffffad600fd2>] asm_call_irq_on_stack+0x12/0x20 [ 1194.054227][ T0] softirqs last disabled at (575043): [<ffffffffad600fd2>] asm_call_irq_on_stack+0x12/0x20 [ 1194.079389][ T0] CPU: 69 PID: 0 Comm: swapper/69 Not tainted 5.10.6-cloudflare-kasan-2021.1.4-dev #1 [ 1194.104103][ T0] Hardware name: NULL R162-Z12-CD/MZ12-HD4-CD, BIOS R10 06/04/2020 [ 1194.119591][ T0] Call Trace: [ 1194.130233][ T0] dump_stack+0x9a/0xcc [ 1194.141617][ T0] ___might_sleep.cold+0x180/0x1b0 [ 1194.153825][ T0] mempool_alloc+0x16b/0x300 [ 1194.165313][ T0] ? remove_element+0x160/0x160 [ 1194.176961][ T0] ? blk_mq_end_request+0x4b/0x490 [ 1194.188778][ T0] crypt_convert+0x27f6/0x45f0 [dm_crypt] [ 1194.201024][ T0] ? rcu_read_lock_sched_held+0x3f/0x70 [ 1194.212906][ T0] ? module_assert_mutex_or_preempt+0x3e/0x70 [ 1194.225318][ T0] ? __module_address.part.0+0x1b/0x3a0 [ 1194.237212][ T0] ? is_kernel_percpu_address+0x5b/0x190 [ 1194.249238][ T0] ? crypt_iv_tcw_ctr+0x4a0/0x4a0 [dm_crypt] [ 1194.261593][ T0] ? is_module_address+0x25/0x40 [ 1194.272905][ T0] ? static_obj+0x8a/0xc0 [ 1194.283582][ T0] ? lockdep_init_map_waits+0x26a/0x700 [ 1194.295570][ T0] ? __raw_spin_lock_init+0x39/0x110 [ 1194.307330][ T0] kcryptd_crypt_read_convert+0x31c/0x560 [dm_crypt] [ 1194.320496][ T0] ? kcryptd_queue_crypt+0x1be/0x380 [dm_crypt] [ 1194.333203][ T0] blk_update_request+0x6d7/0x1500 [ 1194.344841][ T0] ? blk_mq_trigger_softirq+0x190/0x190 [ 1194.356831][ T0] blk_mq_end_request+0x4b/0x490 [ 1194.367994][ T0] ? blk_mq_trigger_softirq+0x190/0x190 [ 1194.379693][ T0] flush_smp_call_function_queue+0x24b/0x560 [ 1194.391847][ T0] flush_smp_call_function_from_idle+0x59/0x80 [ 1194.403969][ T0] do_idle+0x287/0x450 [ 1194.413891][ T0] ? arch_cpu_idle_exit+0x40/0x40 [ 1194.424716][ T0] ? lockdep_hardirqs_on_prepare+0x286/0x3f0 [ 1194.436399][ T0] ? _raw_spin_unlock_irqrestore+0x39/0x40 [ 1194.447759][ T0] cpu_startup_entry+0x19/0x20 [ 1194.458038][ T0] secondary_startup_64_no_verify+0xb0/0xbb IO completion can be queued to a different CPU by the block subsystem as a "call single function/data". The CPU may run these routines from the idle task, but it does so with interrupts disabled. It is not a good idea to do decryption with irqs disabled even in an idle task context, so just defer it to a tasklet as with requests from hard irqs. Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workqueues") Cc: <stable(a)vger.kernel.org> # v5.9+ Signed-off-by: Ignat Korchagin <ignat(a)cloudflare.com> --- drivers/md/dm-crypt.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 53791138d78b..c56b01bfdb60 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -2091,8 +2091,11 @@ static void kcryptd_queue_crypt(struct dm_crypt_io *io) if ((bio_data_dir(io->base_bio) == READ && test_bit(DM_CRYPT_NO_READ_WORKQUEUE, &cc->flags)) || (bio_data_dir(io->base_bio) == WRITE && test_bit(DM_CRYPT_NO_WRITE_WORKQUEUE, &cc->flags))) { - if (in_irq()) { - /* Crypto API's "skcipher_walk_first() refuses to work in hard IRQ context */ + /* in_irq(): Crypto API's "skcipher_walk_first() refuses to work in hard IRQ context. + * irqs_disabled(): the kernel may run some IO completion from the idle thread, but + it is being executed with irqs disabled. + */ + if (in_irq() || irqs_disabled()) { tasklet_init(&io->tasklet, kcryptd_crypt_tasklet, (unsigned long)&io->work); tasklet_schedule(&io->tasklet); return; -- 2.20.1

4 years, 7 months

2
1
0 0

Re: [RFC PATCH 6/8] sched: Report local wake up on resched blind zone within idle loop

by Paul E. McKenney

On Thu, Jan 14, 2021 at 11:46:06AM +0000, Chris Wilson wrote: > Quoting Frederic Weisbecker (2021-01-09 02:05:34) > > +void noinstr sched_resched_local_assert_allowed(void) > > +{ > > + if (this_rq()->resched_local_allow) > > + return; > > + > > + /* > > + * Idle interrupts break the CPU from its pause and > > + * rescheduling happens on idle loop exit. > > + */ > > + if (in_hardirq()) > > + return; > > + > > + /* > > + * What applies to hardirq also applies to softirq as > > + * we assume they execute on hardirq tail. Ksoftirqd > > + * shouldn't have resched_local_allow == 0. > > + * We also assume that no local_bh_enable() call may > > + * execute softirqs inline on fragile idle/entry > > + * path... > > + */ > > + if (in_serving_softirq()) > > + return; > > + > > + WARN_ONCE(1, "Late current task rescheduling may be lost\n"); > > +} > > This warn is impacting all suspend testing in linux-next: Does the patch series here help? https://lore.kernel.org/lkml/20210112144344.850850975@infradead.org/ And in Frederic's defense, his patch isn't causing the problem, but rather calling attention to a condition that can lead to hangs. Thanx, Paul > <4> [124.226839] Late current task rescheduling may be lost > <4> [124.226847] WARNING: CPU: 0 PID: 0 at kernel/sched/core.c:628 sched_resched_local_assert_allowed+0x53/0x60 > <4> [124.226854] Modules linked in: vgem btusb btrtl btbcm btintel snd_hda_codec_hdmi bluetooth snd_hda_codec_realtek snd_hda_codec_generic coretemp ledtrig_audio crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ecdh_generic ecc r8169 realtek i915 lpc_ich snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers > <4> [124.226905] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-rc3-next-20210113-gaa515cdce7a15-next-20210113 #1 > <4> [124.226909] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 > <4> [124.226912] RIP: 0010:sched_resched_local_assert_allowed+0x53/0x60 > <4> [124.226918] Code: a9 00 00 0f 00 75 0e f6 c4 01 75 09 80 3d 55 42 d9 00 00 74 02 5b c3 48 c7 c7 68 0e 31 82 c6 05 43 42 d9 00 01 e8 9c 39 fb ff <0f> 0b 5b c3 cc cc cc cc cc cc cc cc cc 48 39 77 10 0f 84 97 00 00 > <4> [124.226922] RSP: 0018:ffffffff82603cf8 EFLAGS: 00010082 > <4> [124.226926] RAX: 0000000000000000 RBX: 000000000003b280 RCX: 0000000000000007 > <4> [124.226929] RDX: 0000000000000007 RSI: ffffffff8112d041 RDI: 00000000ffffffff > <4> [124.226931] RBP: ffff888121b9a840 R08: 0000000000000000 R09: 0000000000000000 > <4> [124.226934] R10: 00000000ffff0c3c R11: 0000000000000001 R12: ffffffff82603d50 > <4> [124.226937] R13: ffff888121b9b0c8 R14: 0000000000000083 R15: ffff88817b83b280 > <4> [124.226940] FS: 0000000000000000(0000) GS:ffff88817b800000(0000) knlGS:0000000000000000 > <4> [124.226943] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > <4> [124.226946] CR2: 00005645075dd1b0 CR3: 0000000005612000 CR4: 00000000001006f0 > <4> [124.226949] Call Trace: > <4> [124.226951] check_preempt_curr+0x44/0x90 > <4> [124.226956] ttwu_do_wakeup+0x14/0x220 > <4> [124.226961] try_to_wake_up+0x1ef/0x7b0 > <4> [124.226966] ? get_pwq.isra.21+0x2c/0x40 > <4> [124.226972] __queue_work+0x180/0x610 > <4> [124.226977] queue_work_on+0x65/0x70 > <4> [124.226981] timekeeping_resume+0x150/0x1b0 > <4> [124.226986] tick_unfreeze+0x3c/0x120 > <4> [124.226990] cpuidle_enter_s2idle+0xec/0x180 > <4> [124.226995] do_idle+0x1f3/0x2b0 > <4> [124.227000] cpu_startup_entry+0x14/0x20 > <4> [124.227004] start_kernel+0x551/0x576 > <4> [124.227009] secondary_startup_64_no_verify+0xb0/0xbb > <4> [124.227017] irq event stamp: 595206 > <4> [124.227019] hardirqs last enabled at (595205): [<ffffffff81c00c42>] asm_sysvec_apic_timer_interrupt+0x12/0x20 > <4> [124.227024] hardirqs last disabled at (595206): [<ffffffff810ef1da>] do_idle+0xaa/0x2b0 > <4> [124.227028] softirqs last enabled at (595182): [<ffffffff81e00342>] __do_softirq+0x342/0x48e > <4> [124.227033] softirqs last disabled at (595171): [<ffffffff81c00f52>] asm_call_irq_on_stack+0x12/0x20 > <4> [124.227038] ---[ end trace 6fff00bd318698a4 ]--- > <4> [124.227050] > <4> [124.227052] ====================================================== > <4> [124.227054] WARNING: possible circular locking dependency detected > <4> [124.227055] 5.11.0-rc3-next-20210113-gaa515cdce7a15-next-20210113 #1 Not tainted > <4> [124.227056] ------------------------------------------------------ > <4> [124.227058] swapper/0/0 is trying to acquire lock: > <4> [124.227059] ffffffff8272fdb8 ((console_sem).lock){-...}-{2:2}, at: down_trylock+0xa/0x30 > <4> [124.227063] > <4> [124.227064] but task is already holding lock: > <4> [124.227065] ffff88817b83b298 (&rq->lock){-.-.}-{2:2}, at: try_to_wake_up+0x1c9/0x7b0 > <4> [124.227069] > <4> [124.227070] which lock already depends on the new lock. > <4> [124.227071] > <4> [124.227072] > <4> [124.227073] the existing dependency chain (in reverse order) is: > <4> [124.227074] > <4> [124.227074] -> #2 (&rq->lock){-.-.}-{2:2}: > <4> [124.227078] _raw_spin_lock+0x2a/0x40 > <4> [124.227079] task_fork_fair+0x41/0x170 > <4> [124.227080] sched_fork+0x13c/0x240 > <4> [124.227081] copy_process+0x7aa/0x1c70 > <4> [124.227082] kernel_clone+0x98/0x6f0 > <4> [124.227083] kernel_thread+0x50/0x70 > <4> [124.227084] rest_init+0x1d/0x231 > <4> [124.227084] start_kernel+0x551/0x576 > <4> [124.227085] secondary_startup_64_no_verify+0xb0/0xbb > <4> [124.227086] > <4> [124.227087] -> #1 (&p->pi_lock){-.-.}-{2:2}: > <4> [124.227091] _raw_spin_lock_irqsave+0x33/0x50 > <4> [124.227092] try_to_wake_up+0x5a/0x7b0 > <4> [124.227093] up+0x3b/0x50 > <4> [124.227093] __up_console_sem+0x29/0x60 > <4> [124.227094] console_unlock+0x32f/0x580 > <4> [124.227095] con_font_op+0x2af/0x360 > <4> [124.227096] vt_ioctl+0x4f3/0x12b0 > <4> [124.227097] tty_ioctl+0x23d/0x920 > <4> [124.227098] __x64_sys_ioctl+0x6d/0xa0 > <4> [124.227099] do_syscall_64+0x33/0x80 > <4> [124.227100] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > <4> [124.227101] > <4> [124.227101] -> #0 ((console_sem).lock){-...}-{2:2}: > <4> [124.227105] __lock_acquire+0x1502/0x2570 > <4> [124.227106] lock_acquire+0xdc/0x3c0 > <4> [124.227107] _raw_spin_lock_irqsave+0x33/0x50 > <4> [124.227108] down_trylock+0xa/0x30 > <4> [124.227109] __down_trylock_console_sem+0x23/0x90 > <4> [124.227110] console_trylock+0xe/0x60 > <4> [124.227111] vprintk_emit+0x135/0x340 > <4> [124.227112] printk+0x53/0x6a > <4> [124.227113] __warn_printk+0x41/0x82 > <4> [124.227114] sched_resched_local_assert_allowed+0x53/0x60 > <4> [124.227115] check_preempt_curr+0x44/0x90 > <4> [124.227116] ttwu_do_wakeup+0x14/0x220 > <4> [124.227117] try_to_wake_up+0x1ef/0x7b0 > <4> [124.227117] __queue_work+0x180/0x610 > <4> [124.227118] queue_work_on+0x65/0x70 > <4> [124.227119] timekeeping_resume+0x150/0x1b0 > <4> [124.227120] tick_unfreeze+0x3c/0x120 > <4> [124.227121] cpuidle_enter_s2idle+0xec/0x180 > <4> [124.227122] do_idle+0x1f3/0x2b0 > <4> [124.227123] cpu_startup_entry+0x14/0x20 > <4> [124.227124] start_kernel+0x551/0x576 > <4> [124.227125] secondary_startup_64_no_verify+0xb0/0xbb > <4> [124.227126] > <4> [124.227127] other info that might help us debug this: > <4> [124.227127] > <4> [124.227128] Chain exists of: > <4> [124.227129] (console_sem).lock --> &p->pi_lock --> &rq->lock > <4> [124.227134] > <4> [124.227135] Possible unsafe locking scenario: > <4> [124.227136] > <4> [124.227136] CPU0 CPU1 > <4> [124.227137] ---- ---- > <4> [124.227138] lock(&rq->lock); > <4> [124.227140] lock(&p->pi_lock); > <4> [124.227143] lock(&rq->lock); > <4> [124.227145] lock((console_sem).lock); > <4> [124.227147] > <4> [124.227148] *** DEADLOCK *** > <4> [124.227149] > <4> [124.227149] 5 locks held by swapper/0/0: > <4> [124.227150] #0: ffffffff827370f8 (tick_freeze_lock){....}-{2:2}, at: tick_unfreeze+0xc/0x120 > <4> [124.227155] #1: ffffffff82732360 (rcu_read_lock){....}-{1:2}, at: __queue_work+0x54/0x610 > <4> [124.227159] #2: ffff88817b83aa98 (&pool->lock){-.-.}-{2:2}, at: __queue_work+0xe3/0x610 > <4> [124.227164] #3: ffff888121b9b0e0 (&p->pi_lock){-.-.}-{2:2}, at: try_to_wake_up+0x5a/0x7b0 > <4> [124.227169] #4: ffff88817b83b298 (&rq->lock){-.-.}-{2:2}, at: try_to_wake_up+0x1c9/0x7b0 > <4> [124.227173] > <4> [124.227174] stack backtrace: > <4> [124.227175] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-rc3-next-20210113-gaa515cdce7a15-next-20210113 #1 > <4> [124.227177] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 > <4> [124.227178] Call Trace: > <4> [124.227178] dump_stack+0x77/0x97 > <4> [124.227179] check_noncircular+0x12e/0x150 > <4> [124.227180] __lock_acquire+0x1502/0x2570 > <4> [124.227181] lock_acquire+0xdc/0x3c0 > <4> [124.227182] ? down_trylock+0xa/0x30 > <4> [124.227183] ? vprintk_store+0x36a/0x440 > <4> [124.227184] ? vprintk_emit+0x135/0x340 > <4> [124.227185] _raw_spin_lock_irqsave+0x33/0x50 > <4> [124.227185] ? down_trylock+0xa/0x30 > <4> [124.227186] down_trylock+0xa/0x30 > <4> [124.227187] __down_trylock_console_sem+0x23/0x90 > <4> [124.227188] console_trylock+0xe/0x60 > <4> [124.227189] vprintk_emit+0x135/0x340 > <4> [124.227190] printk+0x53/0x6a > <4> [124.227191] __warn_printk+0x41/0x82 > <4> [124.227191] sched_resched_local_assert_allowed+0x53/0x60 > <4> [124.227192] check_preempt_curr+0x44/0x90 > <4> [124.227193] ttwu_do_wakeup+0x14/0x220 > <4> [124.227194] try_to_wake_up+0x1ef/0x7b0 > <4> [124.227195] ? get_pwq.isra.21+0x2c/0x40 > <4> [124.227196] __queue_work+0x180/0x610 > <4> [124.227197] queue_work_on+0x65/0x70 > <4> [124.227198] timekeeping_resume+0x150/0x1b0 > <4> [124.227199] tick_unfreeze+0x3c/0x120 > <4> [124.227199] cpuidle_enter_s2idle+0xec/0x180 > <4> [124.227200] do_idle+0x1f3/0x2b0 > <4> [124.227201] cpu_startup_entry+0x14/0x20 > <4> [124.227202] start_kernel+0x551/0x576 > <4> [124.227203] secondary_startup_64_no_verify+0xb0/0xbb

4 years, 7 months

1
0
0 0

[git:media_tree/master] media: mceusb: Fix potential out-of-bounds shift

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: mceusb: Fix potential out-of-bounds shift Author: James Reynolds <jr(a)memlen.com> Date: Tue Dec 22 13:07:04 2020 +0100 When processing a MCE_RSP_GETPORTSTATUS command, the bit index to set in ir->txports_cabled comes from response data, and isn't validated. As ir->txports_cabled is a u8, nothing should be done if the bit index is greater than 7. Cc: stable(a)vger.kernel.org Reported-by: syzbot+ec3b3128c576e109171d(a)syzkaller.appspotmail.com Signed-off-by: James Reynolds <jr(a)memlen.com> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/rc/mceusb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c index f1dbd059ed08..c8d63673e131 100644 --- a/drivers/media/rc/mceusb.c +++ b/drivers/media/rc/mceusb.c @@ -1169,7 +1169,7 @@ static void mceusb_handle_command(struct mceusb_dev *ir, u8 *buf_in) switch (subcmd) { /* the one and only 5-byte return value command */ case MCE_RSP_GETPORTSTATUS: - if (buf_in[5] == 0) + if (buf_in[5] == 0 && *hi < 8) ir->txports_cabled |= 1 << *hi; break;

4 years, 7 months

1
0
0 0

[git:media_tree/master] media: ir_toy: add another IR Droid device

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: ir_toy: add another IR Droid device Author: Sean Young <sean(a)mess.org> Date: Sun Dec 27 14:45:01 2020 +0100 This device is also supported. Cc: stable(a)vger.kernel.org Tested-by: Georgi Bakalski <georgi.bakalski(a)gmail.com> Reported-by: Georgi Bakalski <georgi.bakalski(a)gmail.com> Signed-off-by: Sean Young <sean(a)mess.org> Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/rc/ir_toy.c | 1 + 1 file changed, 1 insertion(+) --- diff --git a/drivers/media/rc/ir_toy.c b/drivers/media/rc/ir_toy.c index e0242c9b6aeb..3e729a17b35f 100644 --- a/drivers/media/rc/ir_toy.c +++ b/drivers/media/rc/ir_toy.c @@ -491,6 +491,7 @@ static void irtoy_disconnect(struct usb_interface *intf) static const struct usb_device_id irtoy_table[] = { { USB_DEVICE_INTERFACE_CLASS(0x04d8, 0xfd08, USB_CLASS_CDC_DATA) }, + { USB_DEVICE_INTERFACE_CLASS(0x04d8, 0xf58b, USB_CLASS_CDC_DATA) }, { } };

4 years, 7 months

1
0
0 0

[PATCH v5 5/5] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active

by Muchun Song

The page_huge_active() can be called from scan_movable_pages() which do not hold a reference count to the HugeTLB page. So when we call page_huge_active() from scan_movable_pages(), the HugeTLB page can be freed parallel. Then we will trigger a BUG_ON which is in the page_huge_active() when CONFIG_DEBUG_VM is enabled. Just remove the VM_BUG_ON_PAGE. Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: stable(a)vger.kernel.org --- mm/hugetlb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 43b7a044f248..6c5dfef682cc 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1360,8 +1360,7 @@ struct hstate *size_to_hstate(unsigned long size) */ bool page_huge_active(struct page *page) { - VM_BUG_ON_PAGE(!PageHuge(page), page); - return PageHead(page) && PagePrivate(&page[1]); + return PageHeadHuge(page) && PagePrivate(&page[1]); } /* never called for tail page */ -- 2.11.0

4 years, 7 months

1
0
0 0

[PATCH v5 4/5] mm: hugetlb: fix a race between isolating and freeing page

by Muchun Song

There is a race between isolate_huge_page() and __free_huge_page(). CPU0: CPU1: if (PageHuge(page)) put_page(page) __free_huge_page(page) spin_lock(&hugetlb_lock) update_and_free_page(page) set_compound_page_dtor(page, NULL_COMPOUND_DTOR) spin_unlock(&hugetlb_lock) isolate_huge_page(page) // trigger BUG_ON VM_BUG_ON_PAGE(!PageHead(page), page) spin_lock(&hugetlb_lock) page_huge_active(page) // trigger BUG_ON VM_BUG_ON_PAGE(!PageHuge(page), page) spin_unlock(&hugetlb_lock) When we isolate a HugeTLB page on CPU0. Meanwhile, we free it to the buddy allocator on CPU1. Then, we can trigger a BUG_ON on CPU0. Because it is already freed to the buddy allocator. Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: stable(a)vger.kernel.org --- mm/hugetlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 1b789d1fd06b..43b7a044f248 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5574,9 +5574,9 @@ bool isolate_huge_page(struct page *page, struct list_head *list) { bool ret = true; - VM_BUG_ON_PAGE(!PageHead(page), page); spin_lock(&hugetlb_lock); - if (!page_huge_active(page) || !get_page_unless_zero(page)) { + if (!PageHeadHuge(page) || !page_huge_active(page) || + !get_page_unless_zero(page)) { ret = false; goto unlock; } -- 2.11.0

4 years, 7 months

1
0
0 0

[PATCH v5 2/5] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page

by Muchun Song

If a new hugetlb page is allocated during fallocate it will not be marked as active (set_page_huge_active) which will result in a later isolate_huge_page failure when the page migration code would like to move that page. Such a failure would be unexpected and wrong. Only export set_page_huge_active, just leave clear_page_huge_active as static. Because there are no external users. Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate()) Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: stable(a)vger.kernel.org --- fs/hugetlbfs/inode.c | 3 ++- include/linux/hugetlb.h | 2 ++ mm/hugetlb.c | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index b5c109703daa..21c20fd5f9ee 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -735,9 +735,10 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset, mutex_unlock(&hugetlb_fault_mutex_table[hash]); + set_page_huge_active(page); /* * unlock_page because locked by add_to_page_cache() - * page_put due to reference from alloc_huge_page() + * put_page() due to reference from alloc_huge_page() */ unlock_page(page); put_page(page); diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index ebca2ef02212..b5807f23caf8 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -770,6 +770,8 @@ static inline void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, } #endif +void set_page_huge_active(struct page *page); + #else /* CONFIG_HUGETLB_PAGE */ struct hstate {}; diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 1f3bf1710b66..4741d60f8955 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1348,7 +1348,7 @@ bool page_huge_active(struct page *page) } /* never called for tail page */ -static void set_page_huge_active(struct page *page) +void set_page_huge_active(struct page *page) { VM_BUG_ON_PAGE(!PageHeadHuge(page), page); SetPagePrivate(&page[1]); -- 2.11.0

4 years, 7 months

1
0
0 0

[PATCH] mfd: gateworks-gsc: fix interrupt type

by Tim Harvey

The Gateworks System Controller has an active-low interrupt. Fix the interrupt request type. Fixes: d85234994b2f ("mfd: Add Gateworks System Controller core driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> --- drivers/mfd/gateworks-gsc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/gateworks-gsc.c b/drivers/mfd/gateworks-gsc.c index 576da62..d878767 100644 --- a/drivers/mfd/gateworks-gsc.c +++ b/drivers/mfd/gateworks-gsc.c @@ -234,7 +234,7 @@ static int gsc_probe(struct i2c_client *client) ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq, IRQF_ONESHOT | IRQF_SHARED | - IRQF_TRIGGER_FALLING, 0, + IRQF_TRIGGER_LOW, 0, &gsc_irq_chip, &irq_data); if (ret) return ret; -- 2.7.4

4 years, 7 months

2
1
0 0

[PATCH] drm/amdgpu: add green_sardine device id (v2)

by Mengbing Wang

From: Prike Liang <Prike.Liang(a)amd.com> Add green_sardine PCI id support and map it to renoir asic type. v2: add apu flag Signed-off-by: Prike Liang <Prike.Liang(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Huang Rui <ray.huang(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org # 5.10.x --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index f52fa2cf58e2..f523eae461b4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1119,6 +1119,7 @@ static const struct pci_device_id pciidlist[] = { /* Renoir */ {0x1002, 0x1636, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RENOIR|AMD_IS_APU}, + {0x1002, 0x1638, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RENOIR|AMD_IS_APU}, /* Navi12 */ {0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12}, -- 2.17.1

4 years, 7 months

1
0
0 0

patch "USB: gadget: dummy-hcd: Fix errors in port-reset handling" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: gadget: dummy-hcd: Fix errors in port-reset handling to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 6e6aa61d81194c01283880950df563b1b9abec46 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 13 Jan 2021 14:45:10 -0500 Subject: USB: gadget: dummy-hcd: Fix errors in port-reset handling Commit c318840fb2a4 ("USB: Gadget: dummy-hcd: Fix shift-out-of-bounds bug") messed up the way dummy-hcd handles requests to turn on the RESET port feature (I didn't notice that the original switch case ended with a fallthrough). The call to set_link_state() was inadvertently removed, as was the code to set the USB_PORT_STAT_RESET flag when the speed is USB2. In addition, the original code never checked whether the port was connected before handling the port-reset request. There was a check for the port being powered, but it was removed by that commit! In practice this doesn't matter much because the kernel doesn't try to reset disconnected ports, but it's still bad form. This patch fixes these problems by changing the fallthrough to break, adding back in the missing set_link_state() call, setting the port-reset status flag, adding a port-is-connected test, and removing a redundant assignment statement. Fixes: c318840fb2a4 ("USB: Gadget: dummy-hcd: Fix shift-out-of-bounds bug") CC: <stable(a)vger.kernel.org> Acked-by: Felipe Balbi <balbi(a)kernel.org> Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/20210113194510.GA1290698@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/dummy_hcd.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index 1a953f44183a..57067763b100 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -2270,17 +2270,20 @@ static int dummy_hub_control( } fallthrough; case USB_PORT_FEAT_RESET: + if (!(dum_hcd->port_status & USB_PORT_STAT_CONNECTION)) + break; /* if it's already enabled, disable */ if (hcd->speed == HCD_USB3) { - dum_hcd->port_status = 0; dum_hcd->port_status = (USB_SS_PORT_STAT_POWER | USB_PORT_STAT_CONNECTION | USB_PORT_STAT_RESET); - } else + } else { dum_hcd->port_status &= ~(USB_PORT_STAT_ENABLE | USB_PORT_STAT_LOW_SPEED | USB_PORT_STAT_HIGH_SPEED); + dum_hcd->port_status |= USB_PORT_STAT_RESET; + } /* * We want to reset device status. All but the * Self powered feature @@ -2292,7 +2295,8 @@ static int dummy_hub_control( * interval? Is it still 50msec as for HS? */ dum_hcd->re_timeout = jiffies + msecs_to_jiffies(50); - fallthrough; + set_link_state(dum_hcd); + break; case USB_PORT_FEAT_C_CONNECTION: case USB_PORT_FEAT_C_RESET: case USB_PORT_FEAT_C_ENABLE: -- 2.30.0

4 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror