September 2023 - Linux-stable-mirror

[PATCH v5] driver core: platform: set numa_node before platform_add_device()

by Jinhui Guo

platform_add_device() creates the numa_node attribute of sysfs according to whether dev_to_node(dev) is equal to NUMA_NO_NODE. So set the numa node of device before creating numa_node attribute of sysfs. Fixes: 4a60406d3592 ("driver core: platform: expose numa_node to users in sysfs") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309122309.mbxAnAIe-lkp@intel.com/ Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- V4 -> V5: Add Cc: stable line and changes from the previous submited patches V3 -> V4: Refactor code to be an ACPI function call V2 -> V3: Fix Signed-off name V1 -> V2: Fix compile error without enabling CONFIG_ACPI drivers/acpi/acpi_platform.c | 4 +--- drivers/base/platform.c | 1 + include/linux/acpi.h | 5 +++++ 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 48d15dd785f6..adcbfbdc343f 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -178,11 +178,9 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else { - set_dev_node(&pdev->dev, acpi_get_node(adev->handle)); + else dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); - } kfree(resources); diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 76bfcba25003..35c891075d95 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -841,6 +841,7 @@ struct platform_device *platform_device_register_full( goto err; } + set_dev_node(&pdev->dev, ACPI_NODE_GET(ACPI_COMPANION(&pdev->dev))); ret = platform_device_add(pdev); if (ret) { err: diff --git a/include/linux/acpi.h b/include/linux/acpi.h index a73246c3c35e..6a349d53f19e 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -477,6 +477,10 @@ static inline int acpi_get_node(acpi_handle handle) return 0; } #endif + +#define ACPI_NODE_GET(adev) ((adev) && (adev)->handle ? \ + acpi_get_node((adev)->handle) : NUMA_NO_NODE) + extern int pnpacpi_disabled; #define PXM_INVAL (-1) @@ -770,6 +774,7 @@ const char *acpi_get_subsystem_id(acpi_handle handle); #define ACPI_COMPANION_SET(dev, adev) do { } while (0) #define ACPI_HANDLE(dev) (NULL) #define ACPI_HANDLE_FWNODE(fwnode) (NULL) +#define ACPI_NODE_GET(adev) NUMA_NO_NODE #include <acpi/acpi_numa.h> -- 2.20.1

2 years, 3 months

1
0
0 0

[to-be-updated] kasan-fix-access-invalid-shadow-address-when-input-is-illegal.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kasan: fix access invalid shadow address when input is illegal has been removed from the -mm tree. Its filename was kasan-fix-access-invalid-shadow-address-when-input-is-illegal.patch This patch was dropped because an updated version will be merged ------------------------------------------------------ From: Haibo Li <haibo.li(a)mediatek.com> Subject: kasan: fix access invalid shadow address when input is illegal Date: Thu, 14 Sep 2023 16:08:33 +0800 when the input address is illegal,the corresponding shadow address from kasan_mem_to_shadow may have no mapping in mmu table. Access such shadow address causes kernel oops. Here is a sample about oops on arm64(VA 39bit) with KASAN_SW_TAGS on: [ffffffb80aaaaaaa] pgd=000000005d3ce003, p4d=000000005d3ce003, pud=000000005d3ce003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 100 Comm: sh Not tainted 6.6.0-rc1-dirty #43 Hardware name: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __hwasan_load8_noabort+0x5c/0x90 lr : do_ib_ob+0xf4/0x110 ffffffb80aaaaaaa is the shadow address for efffff80aaaaaaaa. The problem is reading invalid shadow in kasan_check_range. The generic kasan also has similar oops. To fix it,check shadow address by reading it with no fault. After this patch,KASAN is able to report invalid memory access for this case. Link: https://lkml.kernel.org/r/20230914080833.50026-1-haibo.li@mediatek.com Signed-off-by: Haibo Li <haibo.li(a)mediatek.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/kasan.h | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/mm/kasan/kasan.h~kasan-fix-access-invalid-shadow-address-when-input-is-illegal +++ a/mm/kasan/kasan.h @@ -304,8 +304,17 @@ static __always_inline bool addr_has_met #ifdef __HAVE_ARCH_SHADOW_MAP return (kasan_mem_to_shadow((void *)addr) != NULL); #else - return (kasan_reset_tag(addr) >= - kasan_shadow_to_mem((void *)KASAN_SHADOW_START)); + u8 *shadow, shadow_val; + + if (kasan_reset_tag(addr) < + kasan_shadow_to_mem((void *)KASAN_SHADOW_START)) + return false; + /* use read with nofault to check whether the shadow is accessible */ + shadow = kasan_mem_to_shadow((void *)addr); + __get_kernel_nofault(&shadow_val, shadow, u8, fault); + return true; +fault: + return false; #endif } _ Patches currently in -mm which might be from haibo.li(a)mediatek.com are

2 years, 3 months

1
0
0 0

[PATCH v1] mmc: Add quirk MMC_QUIRK_BROKEN_CACHE_FLUSH for Micron eMMC Q2J54A

by Bean Huo

From: Bean Huo <beanhuo(a)micron.com> Micron MTFC4GACAJCN eMMC supports cache but requires that flush cache operation be allowed only after a write has occurred. Otherwise, the cache flush command or subsequent commands will time out. Signed-off-by: Bean Huo <beanhuo(a)micron.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/core/core.c | 6 ++++++ drivers/mmc/core/mmc.c | 5 +++++ drivers/mmc/core/quirks.h | 7 ++++--- include/linux/mmc/card.h | 2 ++ 4 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 3d3e0ca52614..5f858eb5f62c 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -259,6 +259,12 @@ static void __mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) host->cqe_ops->cqe_off(host); host->ops->request(host, mrq); + + if (host->card->quirks & MMC_QUIRK_BROKEN_CACHE_FLUSH && !host->card->written_flag) { + if (mrq->cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK || + mrq->cmd->opcode == MMC_WRITE_BLOCK) + host->card->written_flag = true; + } } static void mmc_mrq_pr_debug(struct mmc_host *host, struct mmc_request *mrq, diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 89cd48fcec79..a2edd065fa1b 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -1929,6 +1929,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, if (!oldcard) host->card = card; + card->written_flag = false; + return 0; free_card: @@ -2081,6 +2083,9 @@ static int _mmc_flush_cache(struct mmc_host *host) { int err = 0; + if (host->card->quirks & MMC_QUIRK_BROKEN_CACHE_FLUSH && !host->card->written_flag) + return err; + if (_mmc_cache_enabled(host)) { err = mmc_switch(host->card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_FLUSH_CACHE, 1, diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h index 32b64b564fb1..5e68c8b4cdca 100644 --- a/drivers/mmc/core/quirks.h +++ b/drivers/mmc/core/quirks.h @@ -110,11 +110,12 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = { MMC_QUIRK_TRIM_BROKEN), /* - * Micron MTFC4GACAJCN-1M advertises TRIM but it does not seems to - * support being used to offload WRITE_ZEROES. + * Micron MTFC4GACAJCN-1M supports TRIM but does not appear to suppor + * WRITE_ZEROES offloading. It also supports caching, but the cache can + * only be flushed after a write has occurred. */ MMC_FIXUP("Q2J54A", CID_MANFID_MICRON, 0x014e, add_quirk_mmc, - MMC_QUIRK_TRIM_BROKEN), + MMC_QUIRK_TRIM_BROKEN | MMC_QUIRK_BROKEN_CACHE_FLUSH), /* * Kingston EMMC04G-M627 advertises TRIM but it does not seems to diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h index daa2f40d9ce6..7b12eebc5586 100644 --- a/include/linux/mmc/card.h +++ b/include/linux/mmc/card.h @@ -295,7 +295,9 @@ struct mmc_card { #define MMC_QUIRK_BROKEN_HPI (1<<13) /* Disable broken HPI support */ #define MMC_QUIRK_BROKEN_SD_DISCARD (1<<14) /* Disable broken SD discard support */ #define MMC_QUIRK_BROKEN_SD_CACHE (1<<15) /* Disable broken SD cache support */ +#define MMC_QUIRK_BROKEN_CACHE_FLUSH (1<<16) /* Don't flush cache until the write has occurred */ + bool written_flag; /* Indicates eMMC has been written since power on */ bool reenable_cmdq; /* Re-enable Command Queue */ unsigned int erase_size; /* erase size in sectors */ -- 2.34.1

2 years, 3 months

2
3
0 0

[PATCHv2] nvme: avoid bogus CRTO values

by Keith Busch

From: Keith Busch <kbusch(a)kernel.org> Some devices are reporting Controller Ready Modes Supported, but return 0 for CRTO. These devices require a much higher time to ready than that, so they are failing to initialize after the driver started preferring that value over CAP.TO. The spec requires CAP.TO match the appropritate CRTO value, or be set to 0xff if CRTO is larger than that. This means that CAP.TO can be used to validate if CRTO is reliable, and provides an appropriate fallback for setting the timeout value if not. Use whichever is larger. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217863 Reported-by: Cláudio Sampaio <patola(a)gmail.com> Reported-by: Felix Yan <felixonmars(a)archlinux.org> Based-on-a-patch-by: Felix Yan <felixonmars(a)archlinux.org> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Cc: stable(a)vger.kernel.org Signed-off-by: Keith Busch <kbusch(a)kernel.org> --- v1->v2: Warn once if driver isn't relying on CRTO values drivers/nvme/host/core.c | 54 ++++++++++++++++++++++++++-------------- 1 file changed, 35 insertions(+), 19 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 37b6fa7466620..0685ed4f2dc49 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2245,25 +2245,8 @@ int nvme_enable_ctrl(struct nvme_ctrl *ctrl) else ctrl->ctrl_config = NVME_CC_CSS_NVM; - if (ctrl->cap & NVME_CAP_CRMS_CRWMS) { - u32 crto; - - ret = ctrl->ops->reg_read32(ctrl, NVME_REG_CRTO, &crto); - if (ret) { - dev_err(ctrl->device, "Reading CRTO failed (%d)\n", - ret); - return ret; - } - - if (ctrl->cap & NVME_CAP_CRMS_CRIMS) { - ctrl->ctrl_config |= NVME_CC_CRIME; - timeout = NVME_CRTO_CRIMT(crto); - } else { - timeout = NVME_CRTO_CRWMT(crto); - } - } else { - timeout = NVME_CAP_TIMEOUT(ctrl->cap); - } + if (ctrl->cap & NVME_CAP_CRMS_CRWMS && ctrl->cap & NVME_CAP_CRMS_CRIMS) + ctrl->ctrl_config |= NVME_CC_CRIME; ctrl->ctrl_config |= (NVME_CTRL_PAGE_SHIFT - 12) << NVME_CC_MPS_SHIFT; ctrl->ctrl_config |= NVME_CC_AMS_RR | NVME_CC_SHN_NONE; @@ -2277,6 +2260,39 @@ int nvme_enable_ctrl(struct nvme_ctrl *ctrl) if (ret) return ret; + /* CAP value may change after initial CC write */ + ret = ctrl->ops->reg_read64(ctrl, NVME_REG_CAP, &ctrl->cap); + if (ret) + return ret; + + timeout = NVME_CAP_TIMEOUT(ctrl->cap); + if (ctrl->cap & NVME_CAP_CRMS_CRWMS) { + u32 crto, ready_timeout; + + ret = ctrl->ops->reg_read32(ctrl, NVME_REG_CRTO, &crto); + if (ret) { + dev_err(ctrl->device, "Reading CRTO failed (%d)\n", + ret); + return ret; + } + + /* + * CRTO should always be greater or equal to CAP.TO, but some + * devices are known to get this wrong. Use the larger of the + * two values. + */ + if (ctrl->ctrl_config & NVME_CC_CRIME) + ready_timeout = NVME_CRTO_CRIMT(crto); + else + ready_timeout = NVME_CRTO_CRWMT(crto); + + if (ready_timeout < timeout) + dev_warn_once(ctrl->device, "bad crto:%x cap:%llx\n", + crto, ctrl->cap); + else + timeout = ready_timeout; + } + ctrl->ctrl_config |= NVME_CC_ENABLE; ret = ctrl->ops->reg_write32(ctrl, NVME_REG_CC, ctrl->ctrl_config); if (ret) -- 2.34.1

2 years, 3 months

3
4
0 0

[PATCH v3 1/5] mm/cma: use nth_page() in place of direct struct page manipulation.

by Zi Yan

From: Zi Yan <ziy(a)nvidia.com> When dealing with hugetlb pages, manipulating struct page pointers directly can get to wrong struct page, since struct page is not guaranteed to be contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it properly. Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc") Cc: <stable(a)vger.kernel.org> Signed-off-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Muchun Song <songmuchun(a)bytedance.com> --- mm/cma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/cma.c b/mm/cma.c index da2967c6a223..2b2494fd6b59 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -505,7 +505,7 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, */ if (page) { for (i = 0; i < count; i++) - page_kasan_tag_reset(page + i); + page_kasan_tag_reset(nth_page(page, i)); } if (ret && !no_warn) { -- 2.40.1

2 years, 3 months

3
2
0 0

+ proc-nommu-proc-pid-maps-release-mmap-read-lock.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: proc: nommu: /proc/<pid>/maps: release mmap read lock has been added to the -mm mm-hotfixes-unstable branch. Its filename is proc-nommu-proc-pid-maps-release-mmap-read-lock.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ben Wolsieffer <Ben.Wolsieffer(a)hefring.com> Subject: proc: nommu: /proc/<pid>/maps: release mmap read lock Date: Thu, 14 Sep 2023 12:30:20 -0400 On NOMMU, when running "cat /proc/1/maps" twice the second run hangs. The no-MMU implementation of /proc/<pid>/map doesn't normally release the mmap read lock, because it uses !IS_ERR_OR_NULL(_vml) to determine whether to release the lock. Since _vml is NULL when the end of the mappings is reached, the lock is not released. This code was incorrectly adapted from the MMU implementation, which at the time released the lock in m_next() before returning the last entry. The MMU implementation has diverged further from the no-MMU version since then, so this patch brings their locking and error handling into sync, fixing the bug and hopefully avoiding similar issues in the future. Link: https://lkml.kernel.org/r/20230914163019.4050530-2-ben.wolsieffer@hefring.c… Fixes: 47fecca15c09 ("fs/proc/task_nommu.c: don't use priv->task->mm") Signed-off-by: Ben Wolsieffer <ben.wolsieffer(a)hefring.com> Cc: Giulio Benetti <giulio.benetti(a)benettiengineering.com> Cc: Greg Ungerer <gerg(a)uclinux.org> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_nommu.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) --- a/fs/proc/task_nommu.c~proc-nommu-proc-pid-maps-release-mmap-read-lock +++ a/fs/proc/task_nommu.c @@ -192,11 +192,16 @@ static void *m_start(struct seq_file *m, return ERR_PTR(-ESRCH); mm = priv->mm; - if (!mm || !mmget_not_zero(mm)) + if (!mm || !mmget_not_zero(mm)) { + put_task_struct(priv->task); + priv->task = NULL; return NULL; + } if (mmap_read_lock_killable(mm)) { mmput(mm); + put_task_struct(priv->task); + priv->task = NULL; return ERR_PTR(-EINTR); } @@ -205,23 +210,21 @@ static void *m_start(struct seq_file *m, if (vma) return vma; - mmap_read_unlock(mm); - mmput(mm); return NULL; } -static void m_stop(struct seq_file *m, void *_vml) +static void m_stop(struct seq_file *m, void *v) { struct proc_maps_private *priv = m->private; + struct mm_struct *mm = priv->mm; - if (!IS_ERR_OR_NULL(_vml)) { - mmap_read_unlock(priv->mm); - mmput(priv->mm); - } - if (priv->task) { - put_task_struct(priv->task); - priv->task = NULL; - } + if (!priv->task) + return; + + mmap_read_unlock(mm); + mmput(mm); + put_task_struct(priv->task); + priv->task = NULL; } static void *m_next(struct seq_file *m, void *_p, loff_t *pos) _ Patches currently in -mm which might be from Ben.Wolsieffer(a)hefring.com are proc-nommu-proc-pid-maps-release-mmap-read-lock.patch

2 years, 3 months

1
0
0 0

[PATCH 0/5] selftests/resctrl: Fixes to failing tests

by Ilpo Järvinen

Fix three issues with resctrl selftests. The signal handling fix became necessary after the mount/umount fixes. The other two came up when I ran resctrl selftests across the server fleet in our lab to validate the upcoming CAT test rewrite (the rewrite is not part of this series). These are developed and should apply cleanly at least on top the benchmark cleanup series (might apply cleanly also w/o the benchmark series, I didn't test). Ilpo Järvinen (5): selftests/resctrl: Extend signal handler coverage to unmount on receiving signal selftests/resctrl: Remove duplicate feature check from CMT test selftests/resctrl: Refactor feature check to use resource and feature name selftests/resctrl: Fix feature checks selftests/resctrl: Reduce failures due to outliers in MBA/MBM tests tools/testing/selftests/resctrl/cat_test.c | 8 --- tools/testing/selftests/resctrl/cmt_test.c | 3 - tools/testing/selftests/resctrl/mba_test.c | 2 +- tools/testing/selftests/resctrl/mbm_test.c | 2 +- tools/testing/selftests/resctrl/resctrl.h | 6 +- .../testing/selftests/resctrl/resctrl_tests.c | 37 ++++++++-- tools/testing/selftests/resctrl/resctrl_val.c | 22 +++--- tools/testing/selftests/resctrl/resctrlfs.c | 69 ++++++++----------- 8 files changed, 73 insertions(+), 76 deletions(-) -- 2.30.2

2 years, 3 months

2
24
0 0

[PATCH] init/main: Clear boot task idle flag

by Liam R. Howlett

Initial booting is setting the task flag to idle (PF_IDLE) by the call path sched_init() -> init_idle(). Having the task idle and calling call_rcu() in kernel/rcu/tiny.c means that TIF_NEED_RESCHED will be set. Subsequent calls to any cond_resched() will enable IRQs, potentially earlier than the IRQ setup has completed. Recent changes have caused just this scenario and IRQs have been enabled early. This causes a warning later in start_kernel() as interrupts are enabled before they are fully set up. Fix this issue by clearing the PF_IDLE flag on return from sched_init() and restore the flag in rest_init(). Although the boot task was marked as idle since (at least) d80e4fda576d, I am not sure that it is wrong to do so. The forced context-switch on idle task was introduced in the tiny_rcu update, so I'm going to claim this fixes 5f6130fa52ee. Link: https://lore.kernel.org/linux-mm/87v8cv22jh.fsf@mail.lhotse/ Link: https://lore.kernel.org/linux-mm/CAMuHMdWpvpWoDa=Ox-do92czYRvkok6_x6pYUH+Zo… Fixes: 5f6130fa52ee ("tiny_rcu: Directly force QS when call_rcu_[bh|sched]() on idle_task") Cc: stable(a)vger.kernel.org Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: "Paul E. McKenney" <paulmck(a)kernel.org> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Andreas Schwab <schwab(a)linux-m68k.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Peng Zhang <zhangpeng.00(a)bytedance.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: "Mike Rapoport (IBM)" <rppt(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> --- init/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/init/main.c b/init/main.c index ad920fac325c..f74772acf612 100644 --- a/init/main.c +++ b/init/main.c @@ -696,7 +696,7 @@ noinline void __ref __noreturn rest_init(void) */ rcu_read_lock(); tsk = find_task_by_pid_ns(pid, &init_pid_ns); - tsk->flags |= PF_NO_SETAFFINITY; + tsk->flags |= PF_NO_SETAFFINITY | PF_IDLE; set_cpus_allowed_ptr(tsk, cpumask_of(smp_processor_id())); rcu_read_unlock(); @@ -938,6 +938,8 @@ void start_kernel(void) * time - but meanwhile we still have a functioning scheduler. */ sched_init(); + /* Avoid early context switch, rest_init() restores PF_IDLE */ + current->flags &= ~PF_IDLE; if (WARN(!irqs_disabled(), "Interrupts were enabled *very* early, fixing it\n")) -- 2.39.2

2 years, 3 months

6
10
0 0

[PATCH] power: supply: rk817: Add missing module alias

by Nicolas Frattaroli

Similar to the rk817 codec alias that was missing, the rk817 charger driver is missing a module alias as well. This absence prevents the driver from autoprobing on OF systems when it is built as a module. Add the right MODULE_ALIAS to fix this. Fixes: 11cb8da0189b ("power: supply: Add charger driver for Rockchip RK817") Cc: stable(a)vger.kernel.org Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas(a)gmail.com> --- drivers/power/supply/rk817_charger.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/power/supply/rk817_charger.c b/drivers/power/supply/rk817_charger.c index 1a2143641e66..76b991e112da 100644 --- a/drivers/power/supply/rk817_charger.c +++ b/drivers/power/supply/rk817_charger.c @@ -1211,3 +1211,4 @@ MODULE_DESCRIPTION("Battery power supply driver for RK817 PMIC"); MODULE_AUTHOR("Maya Matuszczyk <maccraft123mc(a)gmail.com>"); MODULE_AUTHOR("Chris Morgan <macromorgan(a)hotmail.com>"); MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:rk817-charger"); -- 2.41.0

2 years, 3 months

3
2
0 0

+ mm-memcontrol-fix-gfp_nofs-recursion-in-memoryhigh-enforcement.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: memcontrol: fix GFP_NOFS recursion in memory.high enforcement has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memcontrol-fix-gfp_nofs-recursion-in-memoryhigh-enforcement.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Johannes Weiner <hannes(a)cmpxchg.org> Subject: mm: memcontrol: fix GFP_NOFS recursion in memory.high enforcement Date: Thu, 14 Sep 2023 11:21:39 -0400 Breno and Josef report a deadlock scenario from cgroup reclaim re-entering the filesystem: [ 361.546690] ====================================================== [ 361.559210] WARNING: possible circular locking dependency detected [ 361.571703] 6.5.0-0_fbk700_debug_rc0_kbuilder_13159_gbf787a128001 #1 Tainted: G S E [ 361.589704] ------------------------------------------------------ [ 361.602277] find/9315 is trying to acquire lock: [ 361.611625] ffff88837ba140c0 (&delayed_node->mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0x68/0x4f0 [ 361.631437] [ 361.631437] but task is already holding lock: [ 361.643243] ffff8881765b8678 (btrfs-tree-01){++++}-{4:4}, at: btrfs_tree_read_lock+0x1e/0x40 [ 362.904457] mutex_lock_nested+0x1c/0x30 [ 362.912414] __btrfs_release_delayed_node+0x68/0x4f0 [ 362.922460] btrfs_evict_inode+0x301/0x770 [ 362.982726] evict+0x17c/0x380 [ 362.988944] prune_icache_sb+0x100/0x1d0 [ 363.005559] super_cache_scan+0x1f8/0x260 [ 363.013695] do_shrink_slab+0x2a2/0x540 [ 363.021489] shrink_slab_memcg+0x237/0x3d0 [ 363.050606] shrink_slab+0xa7/0x240 [ 363.083382] shrink_node_memcgs+0x262/0x3b0 [ 363.091870] shrink_node+0x1a4/0x720 [ 363.099150] shrink_zones+0x1f6/0x5d0 [ 363.148798] do_try_to_free_pages+0x19b/0x5e0 [ 363.157633] try_to_free_mem_cgroup_pages+0x266/0x370 [ 363.190575] reclaim_high+0x16f/0x1f0 [ 363.208409] mem_cgroup_handle_over_high+0x10b/0x270 [ 363.246678] try_charge_memcg+0xaf2/0xc70 [ 363.304151] charge_memcg+0xf0/0x350 [ 363.320070] __mem_cgroup_charge+0x28/0x40 [ 363.328371] __filemap_add_folio+0x870/0xd50 [ 363.371303] filemap_add_folio+0xdd/0x310 [ 363.399696] __filemap_get_folio+0x2fc/0x7d0 [ 363.419086] pagecache_get_page+0xe/0x30 [ 363.427048] alloc_extent_buffer+0x1cd/0x6a0 [ 363.435704] read_tree_block+0x43/0xc0 [ 363.443316] read_block_for_search+0x361/0x510 [ 363.466690] btrfs_search_slot+0xc8c/0x1520 This is caused by the mem_cgroup_handle_over_high() not respecting the gfp_mask of the allocation context. We used to only call this function on resume to userspace, where no locks were held. But c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges") added a call from the allocation context without considering the gfp. Link: https://lkml.kernel.org/r/20230914152139.100822-1-hannes@cmpxchg.org Fixes: c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reported-by: Breno Leitao <leitao(a)debian.org> Reported-by: Josef Bacik <josef(a)toxicpanda.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: <stable(a)vger.kernel.org> [5.17+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memcontrol.h | 4 ++-- include/linux/resume_user_mode.h | 2 +- mm/memcontrol.c | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) --- a/include/linux/memcontrol.h~mm-memcontrol-fix-gfp_nofs-recursion-in-memoryhigh-enforcement +++ a/include/linux/memcontrol.h @@ -920,7 +920,7 @@ unsigned long mem_cgroup_get_zone_lru_si return READ_ONCE(mz->lru_zone_size[zone_idx][lru]); } -void mem_cgroup_handle_over_high(void); +void mem_cgroup_handle_over_high(gfp_t gfp_mask); unsigned long mem_cgroup_get_max(struct mem_cgroup *memcg); @@ -1458,7 +1458,7 @@ static inline void mem_cgroup_unlock_pag rcu_read_unlock(); } -static inline void mem_cgroup_handle_over_high(void) +static inline void mem_cgroup_handle_over_high(gfp_t gfp_mask) { } --- a/include/linux/resume_user_mode.h~mm-memcontrol-fix-gfp_nofs-recursion-in-memoryhigh-enforcement +++ a/include/linux/resume_user_mode.h @@ -55,7 +55,7 @@ static inline void resume_user_mode_work } #endif - mem_cgroup_handle_over_high(); + mem_cgroup_handle_over_high(GFP_KERNEL); blkcg_maybe_throttle_current(); rseq_handle_notify_resume(NULL, regs); --- a/mm/memcontrol.c~mm-memcontrol-fix-gfp_nofs-recursion-in-memoryhigh-enforcement +++ a/mm/memcontrol.c @@ -2555,7 +2555,7 @@ static unsigned long calculate_high_dela * Scheduled by try_charge() to be executed from the userland return path * and reclaims memory over the high limit. */ -void mem_cgroup_handle_over_high(void) +void mem_cgroup_handle_over_high(gfp_t gfp_mask) { unsigned long penalty_jiffies; unsigned long pflags; @@ -2583,7 +2583,7 @@ retry_reclaim: */ nr_reclaimed = reclaim_high(memcg, in_retry ? SWAP_CLUSTER_MAX : nr_pages, - GFP_KERNEL); + gfp_mask); /* * memory.high is breached and reclaim is unable to keep up. Throttle @@ -2819,7 +2819,7 @@ done_restock: if (current->memcg_nr_pages_over_high > MEMCG_CHARGE_BATCH && !(current->flags & PF_MEMALLOC) && gfpflags_allow_blocking(gfp_mask)) { - mem_cgroup_handle_over_high(); + mem_cgroup_handle_over_high(gfp_mask); } return 0; } _ Patches currently in -mm which might be from hannes(a)cmpxchg.org are mm-page_alloc-fix-cma-and-highatomic-landing-on-the-wrong-buddy-list.patch mm-memcontrol-fix-gfp_nofs-recursion-in-memoryhigh-enforcement.patch mm-page_alloc-remove-pcppage-migratetype-caching.patch mm-page_alloc-fix-up-block-types-when-merging-compatible-blocks.patch mm-page_alloc-move-free-pages-when-converting-block-during-isolation.patch mm-page_alloc-fix-move_freepages_block-range-error.patch mm-page_alloc-fix-freelist-movement-during-block-conversion.patch mm-page_alloc-consolidate-free-page-accounting.patch

2 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023