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

[PATCH] cifs: fix interrupted close commands

by Paulo Alcantara

Retry close command if it gets interrupted to not leak open handles on the server. Signed-off-by: Paulo Alcantara (SUSE) <pc(a)cjr.nz> Reported-by: Duncan Findlay <duncf(a)duncf.ca> Suggested-by: Pavel Shilovsky <pshilov(a)microsoft.com> Fixes: 6988a619f5b7 ("cifs: allow syscalls to be restarted in __smb_send_rqst()") Cc: stable(a)vger.kernel.org --- fs/cifs/smb2pdu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 067eb44c7baa..794fc3b68b4f 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -3248,7 +3248,7 @@ __SMB2_close(const unsigned int xid, struct cifs_tcon *tcon, free_rsp_buf(resp_buftype, rsp); /* retry close in a worker thread if this one is interrupted */ - if (rc == -EINTR) { + if (is_interrupt_error(rc)) { int tmp_rc; tmp_rc = smb2_handle_cancelled_close(tcon, persistent_fid, -- 2.29.2

4 years, 7 months

4
3
0 0

[PATCH v5 3/5] mm: hugetlb: fix a race between freeing and dissolving the page

by Muchun Song

There is a race condition between __free_huge_page() and dissolve_free_huge_page(). CPU0: CPU1: // page_count(page) == 1 put_page(page) __free_huge_page(page) dissolve_free_huge_page(page) spin_lock(&hugetlb_lock) // PageHuge(page) && !page_count(page) update_and_free_page(page) // page is freed to the buddy spin_unlock(&hugetlb_lock) spin_lock(&hugetlb_lock) clear_page_huge_active(page) enqueue_huge_page(page) // It is wrong, the page is already freed spin_unlock(&hugetlb_lock) The race windows is between put_page() and dissolve_free_huge_page(). We should make sure that the page is already on the free list when it is dissolved. 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> Cc: stable(a)vger.kernel.org --- mm/hugetlb.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 4741d60f8955..1b789d1fd06b 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -79,6 +79,21 @@ DEFINE_SPINLOCK(hugetlb_lock); static int num_fault_mutexes; struct mutex *hugetlb_fault_mutex_table ____cacheline_aligned_in_smp; +static inline bool PageHugeFreed(struct page *head) +{ + return page_private(head + 4) == -1UL; +} + +static inline void SetPageHugeFreed(struct page *head) +{ + set_page_private(head + 4, -1UL); +} + +static inline void ClearPageHugeFreed(struct page *head) +{ + set_page_private(head + 4, 0); +} + /* Forward declaration */ static int hugetlb_acct_memory(struct hstate *h, long delta); @@ -1028,6 +1043,7 @@ static void enqueue_huge_page(struct hstate *h, struct page *page) list_move(&page->lru, &h->hugepage_freelists[nid]); h->free_huge_pages++; h->free_huge_pages_node[nid]++; + SetPageHugeFreed(page); } static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid) @@ -1044,6 +1060,7 @@ static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid) list_move(&page->lru, &h->hugepage_activelist); set_page_refcounted(page); + ClearPageHugeFreed(page); h->free_huge_pages--; h->free_huge_pages_node[nid]--; return page; @@ -1504,6 +1521,7 @@ static void prep_new_huge_page(struct hstate *h, struct page *page, int nid) spin_lock(&hugetlb_lock); h->nr_huge_pages++; h->nr_huge_pages_node[nid]++; + ClearPageHugeFreed(page); spin_unlock(&hugetlb_lock); } @@ -1754,6 +1772,7 @@ int dissolve_free_huge_page(struct page *page) { int rc = -EBUSY; +retry: /* Not to disrupt normal path by vainly holding hugetlb_lock */ if (!PageHuge(page)) return 0; @@ -1770,6 +1789,28 @@ int dissolve_free_huge_page(struct page *page) int nid = page_to_nid(head); if (h->free_huge_pages - h->resv_huge_pages == 0) goto out; + + /* + * We should make sure that the page is already on the free list + * when it is dissolved. + */ + if (unlikely(!PageHugeFreed(head))) { + spin_unlock(&hugetlb_lock); + + /* + * Theoretically, we should return -EBUSY when we + * encounter this race. In fact, we have a chance + * to successfully dissolve the page if we do a + * retry. Because the race window is quite small. + * If we seize this opportunity, it is an optimization + * for increasing the success rate of dissolving page. + */ + while (PageHeadHuge(head) && !PageHugeFreed(head)) + cond_resched(); + + goto retry; + } + /* * Move PageHWPoison flag from head page to the raw error page, * which makes any subpages rather than the error page reusable. -- 2.11.0

4 years, 7 months

2
4
0 0

[PATCH] mtd: rawnand: nandsim: Fix the logic when selecting Hamming soft ECC engine

by Miquel Raynal

I have been fooled by the logic picking the right ECC engine which is spread across two functions: *init_module() and *_attach(). I thought this driver was not impacted by the recent changes around the ECC engines DT parsing logic but in fact it is. Reported-by: kernel test robot <oliver.sang(a)intel.com> Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nandsim.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c index f2b9250c0ea8..0750121ac371 100644 --- a/drivers/mtd/nand/raw/nandsim.c +++ b/drivers/mtd/nand/raw/nandsim.c @@ -2210,6 +2210,9 @@ static int ns_attach_chip(struct nand_chip *chip) { unsigned int eccsteps, eccbytes; + chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + chip->ecc.algo = bch ? NAND_ECC_ALGO_BCH : NAND_ECC_ALGO_HAMMING; + if (!bch) return 0; @@ -2233,8 +2236,6 @@ static int ns_attach_chip(struct nand_chip *chip) return -EINVAL; } - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_BCH; chip->ecc.size = 512; chip->ecc.strength = bch; chip->ecc.bytes = eccbytes; @@ -2273,8 +2274,6 @@ static int __init ns_init_module(void) nsmtd = nand_to_mtd(chip); nand_set_controller_data(chip, (void *)ns); - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - chip->ecc.algo = NAND_ECC_ALGO_HAMMING; /* The NAND_SKIP_BBTSCAN option is necessary for 'overridesize' */ /* and 'badblocks' parameters to work */ chip->options |= NAND_SKIP_BBTSCAN; -- 2.20.1

4 years, 7 months

1
1
0 0

[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

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror