December 2023 - Linux-stable-mirror

[PATCH] Bluetooth: Fix atomicity violation in {conn,adv}_{min,max}_interval_set

by Gui-Dong Han

In {conn,adv}_min_interval_set(): if (val < ... || val > ... || val > hdev->le_{conn,adv}_max_interval) return -EINVAL; hci_dev_lock(hdev); hdev->le_{conn,adv}_min_interval = val; hci_dev_unlock(hdev); In {conn,adv}_max_interval_set(): if (val < ... || val > ... || val < hdev->le_{conn,adv}_min_interval) return -EINVAL; hci_dev_lock(hdev); hdev->le_{conn,adv}_max_interval hci_dev_unlock(hdev); The atomicity violation occurs due to concurrent execution of set_min and set_max funcs which may lead to inconsistent reads and writes of the min value and the max value. The checks for value validity are ineffective as the min/max values could change immediately after being checked, raising the risk of the min value being greater than the max value and causing invalid settings. This possible bug is found by an experimental static analysis tool developed by our team, BassCheck[1]. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 5.17. To resolve this issue, it is suggested to encompass the validity checks within the locked sections in both set_min and set_max funcs. The modification ensures that the validation of 'val' against the current min/max values is atomic, thus maintaining the integrity of the settings. With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the lack of associated hardware, we cannot test the patch in runtime testing, and just verify it according to the code logic. [1] https://sites.google.com/view/basscheck/ Fixes: 3a5c82b78fd28 ("Bluetooth: Move LE debugfs file creation into ...") Cc: stable(a)vger.kernel.org Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- net/bluetooth/hci_debugfs.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c index 6b7741f6e95b..6fdda807f2cf 100644 --- a/net/bluetooth/hci_debugfs.c +++ b/net/bluetooth/hci_debugfs.c @@ -849,11 +849,13 @@ DEFINE_SHOW_ATTRIBUTE(long_term_keys); static int conn_min_interval_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val < 0x0006 || val > 0x0c80 || val > hdev->le_conn_max_interval) + + hci_dev_lock(hdev); + if (val < 0x0006 || val > 0x0c80 || val > hdev->le_conn_max_interval) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->le_conn_min_interval = val; hci_dev_unlock(hdev); @@ -877,11 +879,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(conn_min_interval_fops, conn_min_interval_get, static int conn_max_interval_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val < 0x0006 || val > 0x0c80 || val < hdev->le_conn_min_interval) + + hci_dev_lock(hdev); + if (val < 0x0006 || val > 0x0c80 || val < hdev->le_conn_min_interval) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->le_conn_max_interval = val; hci_dev_unlock(hdev); @@ -989,11 +993,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(adv_channel_map_fops, adv_channel_map_get, static int adv_min_interval_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val < 0x0020 || val > 0x4000 || val > hdev->le_adv_max_interval) + + hci_dev_lock(hdev); + if (val < 0x0020 || val > 0x4000 || val > hdev->le_adv_max_interval) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->le_adv_min_interval = val; hci_dev_unlock(hdev); @@ -1018,10 +1024,12 @@ static int adv_max_interval_set(void *data, u64 val) { struct hci_dev *hdev = data; - if (val < 0x0020 || val > 0x4000 || val < hdev->le_adv_min_interval) + hci_dev_lock(hdev); + if (val < 0x0020 || val > 0x4000 || val < hdev->le_adv_min_interval) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->le_adv_max_interval = val; hci_dev_unlock(hdev); -- 2.34.1

10 months

2
2
0 0

[PATCH 1/4] mtd: rawnand: Prevent crossing LUN boundaries during sequential reads

by Miquel Raynal

The ONFI specification states that devices do not need to support sequential reads across LUN boundaries. In order to prevent such event from happening and possibly failing, let's introduce the concept of "pause" in the sequential read to handle these cases. The first/last pages remain the same but any time we cross a LUN boundary we will end and restart (if relevant) the sequential read operation. Cc: stable(a)vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nand_base.c | 43 +++++++++++++++++++++++++++----- include/linux/mtd/rawnand.h | 2 ++ 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 9e24bedffd89..04e80ace4182 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -1207,6 +1207,23 @@ static int nand_lp_exec_read_page_op(struct nand_chip *chip, unsigned int page, return nand_exec_op(chip, &op); } +static void rawnand_cap_cont_reads(struct nand_chip *chip) +{ + struct nand_memory_organization *memorg; + unsigned int pages_per_lun, first_lun, last_lun; + + memorg = nanddev_get_memorg(&chip->base); + pages_per_lun = memorg->pages_per_eraseblock * memorg->eraseblocks_per_lun; + first_lun = chip->cont_read.first_page / pages_per_lun; + last_lun = chip->cont_read.last_page / pages_per_lun; + + /* Prevent sequential cache reads across LUN boundaries */ + if (first_lun != last_lun) + chip->cont_read.pause_page = first_lun * pages_per_lun + pages_per_lun - 1; + else + chip->cont_read.pause_page = chip->cont_read.last_page; +} + static int nand_lp_exec_cont_read_page_op(struct nand_chip *chip, unsigned int page, unsigned int offset_in_page, void *buf, unsigned int len, bool check_only) @@ -1225,7 +1242,7 @@ static int nand_lp_exec_cont_read_page_op(struct nand_chip *chip, unsigned int p NAND_OP_DATA_IN(len, buf, 0), }; struct nand_op_instr cont_instrs[] = { - NAND_OP_CMD(page == chip->cont_read.last_page ? + NAND_OP_CMD(page == chip->cont_read.pause_page ? NAND_CMD_READCACHEEND : NAND_CMD_READCACHESEQ, NAND_COMMON_TIMING_NS(conf, tWB_max)), NAND_OP_WAIT_RDY(NAND_COMMON_TIMING_MS(conf, tR_max), @@ -1262,16 +1279,29 @@ static int nand_lp_exec_cont_read_page_op(struct nand_chip *chip, unsigned int p } if (page == chip->cont_read.first_page) - return nand_exec_op(chip, &start_op); + ret = nand_exec_op(chip, &start_op); else - return nand_exec_op(chip, &cont_op); + ret = nand_exec_op(chip, &cont_op); + if (ret) + return ret; + + if (!chip->cont_read.ongoing) + return 0; + + if (page == chip->cont_read.pause_page && + page != chip->cont_read.last_page) { + chip->cont_read.first_page = chip->cont_read.pause_page + 1; + rawnand_cap_cont_reads(chip); + } else if (page == chip->cont_read.last_page) { + chip->cont_read.ongoing = false; + } + + return 0; } static bool rawnand_cont_read_ongoing(struct nand_chip *chip, unsigned int page) { - return chip->cont_read.ongoing && - page >= chip->cont_read.first_page && - page <= chip->cont_read.last_page; + return chip->cont_read.ongoing && page >= chip->cont_read.first_page; } /** @@ -3445,6 +3475,7 @@ static void rawnand_enable_cont_reads(struct nand_chip *chip, unsigned int page, if (col) chip->cont_read.first_page++; chip->cont_read.last_page = page + ((readlen >> chip->page_shift) & chip->pagemask); + rawnand_cap_cont_reads(chip); } /** diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h index c29ace15a053..9d0fc5109af6 100644 --- a/include/linux/mtd/rawnand.h +++ b/include/linux/mtd/rawnand.h @@ -1265,6 +1265,7 @@ struct nand_secure_region { * @cont_read: Sequential page read internals * @cont_read.ongoing: Whether a continuous read is ongoing or not * @cont_read.first_page: Start of the continuous read operation + * @cont_read.pause_page: End of the current sequential cache read operation * @cont_read.last_page: End of the continuous read operation * @controller: The hardware controller structure which is shared among multiple * independent devices @@ -1321,6 +1322,7 @@ struct nand_chip { struct { bool ongoing; unsigned int first_page; + unsigned int pause_page; unsigned int last_page; } cont_read; -- 2.34.1

10 months

1
1
0 0

[PATCH 2/4] mtd: rawnand: Fix core interference with sequential reads

by Miquel Raynal

A couple of reports pointed at some strange failures happening a bit randomly since the introduction of sequential page reads support. After investigation it turned out the most likely reason for these issues was the fact that sometimes a (longer) read might happen, starting at the same page that was read previously. This is optimized by the raw NAND core, by not sending the READ_PAGE command to the NAND device and just reading out the data in a local cache. When this page is also flagged as being the starting point for a sequential read, it means the page right next will be accessed without the right instructions. The NAND chip will be confused and will not output correct data. In order to avoid such situation from happening anymore, we can however handle this case with a bit of additional logic, to postpone the initialization of the read sequence by one page. Reported-by: Alexander Shiyan <eagle.alexander923(a)gmail.com> Closes: https://lore.kernel.org/linux-mtd/CAP1tNvS=NVAm-vfvYWbc3k9Cx9YxMc2uZZkmXk8h… Reported-by: Måns Rullgård <mans(a)mansr.com> Closes: https://lore.kernel.org/linux-mtd/yw1xfs6j4k6q.fsf@mansr.com/ Reported-by: Martin Hundebøll <martin(a)geanix.com> Closes: https://lore.kernel.org/linux-mtd/9d0c42fcde79bfedfe5b05d6a4e9fdef71d3dd52.… Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nand_base.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 04e80ace4182..1b0a984d181d 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -3478,6 +3478,18 @@ static void rawnand_enable_cont_reads(struct nand_chip *chip, unsigned int page, rawnand_cap_cont_reads(chip); } +static void rawnand_cont_read_skip_first_page(struct nand_chip *chip, unsigned int page) +{ + if (!chip->cont_read.ongoing || page != chip->cont_read.first_page) + return; + + chip->cont_read.first_page++; + if (chip->cont_read.first_page == chip->cont_read.pause_page) + chip->cont_read.first_page++; + if (chip->cont_read.first_page >= chip->cont_read.last_page) + chip->cont_read.ongoing = false; +} + /** * nand_setup_read_retry - [INTERN] Set the READ RETRY mode * @chip: NAND chip object @@ -3652,6 +3664,8 @@ static int nand_do_read_ops(struct nand_chip *chip, loff_t from, buf += bytes; max_bitflips = max_t(unsigned int, max_bitflips, chip->pagecache.bitflips); + + rawnand_cont_read_skip_first_page(chip, page); } readlen -= bytes; -- 2.34.1

10 months

1
1
0 0

[PATCH 3/4] mtd: rawnand: Prevent sequential reads with on-die ECC engines

by Miquel Raynal

Some devices support sequential reads when using the on-die ECC engines, some others do not. It is a bit hard to know which ones will break other than experimentally, so in order to avoid such a difficult and painful task, let's just pretend all devices should avoid using this optimization when configured like this. Cc: stable(a)vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nand_base.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 1b0a984d181d..139fdf3e58c0 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -5170,6 +5170,14 @@ static void rawnand_late_check_supported_ops(struct nand_chip *chip) /* The supported_op fields should not be set by individual drivers */ WARN_ON_ONCE(chip->controller->supported_op.cont_read); + /* + * Too many devices do not support sequential cached reads with on-die + * ECC correction enabled, so in this case refuse to perform the + * automation. + */ + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE) + return; + if (!nand_has_exec_op(chip)) return; -- 2.34.1

10 months

1
1
0 0

[PATCH] Bluetooth: Fix atomicity violation in conn_info_{min,max}_age_set

by Gui-Dong Han

In conn_info_min_age_set(): if (val == 0 || val > hdev->conn_info_max_age) return -EINVAL; hci_dev_lock(hdev); hdev->conn_info_min_age = val; hci_dev_unlock(hdev); In conn_info_max_age_set(): if (val == 0 || val < hdev->conn_info_min_age) return -EINVAL; hci_dev_lock(hdev); hdev->conn_info_max_age = val; hci_dev_unlock(hdev); The atomicity violation occurs due to concurrent execution of set_min and set_max funcs which may lead to inconsistent reads and writes of the min value and the max value. The checks for value validity are ineffective as the min/max values could change immediately after being checked, raising the risk of the min value being greater than the max value and causing invalid settings. This possible bug is found by an experimental static analysis tool developed by our team, BassCheck[1]. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 5.17. To resolve this issue, it is suggested to encompass the validity checks within the locked sections in both set_min and set_max funcs. The modification ensures that the validation of 'val' against the current min/max values is atomic, thus maintaining the integrity of the settings. With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the lack of associated hardware, we cannot test the patch in runtime testing, and just verify it according to the code logic. [1] https://sites.google.com/view/basscheck/ Fixes: 40ce72b1951c5 ("Bluetooth: Move common debugfs file creation ...") Cc: stable(a)vger.kernel.org Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- net/bluetooth/hci_debugfs.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c index 6b7741f6e95b..d4ce2769c939 100644 --- a/net/bluetooth/hci_debugfs.c +++ b/net/bluetooth/hci_debugfs.c @@ -217,11 +217,13 @@ DEFINE_SHOW_ATTRIBUTE(remote_oob); static int conn_info_min_age_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val == 0 || val > hdev->conn_info_max_age) + + hci_dev_lock(hdev); + if (val == 0 || val > hdev->conn_info_max_age) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->conn_info_min_age = val; hci_dev_unlock(hdev); @@ -245,11 +247,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(conn_info_min_age_fops, conn_info_min_age_get, static int conn_info_max_age_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val == 0 || val < hdev->conn_info_min_age) + + hci_dev_lock(hdev); + if (val == 0 || val < hdev->conn_info_min_age) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->conn_info_max_age = val; hci_dev_unlock(hdev); -- 2.34.1

10 months

1
0
0 0

[PATCH] Bluetooth: Fix atomicity violation in sniff_{min,max}_interval_set

by Gui-Dong Han

In sniff_min_interval_set(): if (val == 0 || val % 2 || val > hdev->sniff_max_interval) return -EINVAL; hci_dev_lock(hdev); hdev->sniff_min_interval = val; hci_dev_unlock(hdev); In sniff_max_interval_set(): if (val == 0 || val % 2 || val < hdev->sniff_min_interval) return -EINVAL; hci_dev_lock(hdev); hdev->sniff_max_interval = val; hci_dev_unlock(hdev); The atomicity violation occurs due to concurrent execution of set_min and set_max funcs which may lead to inconsistent reads and writes of the min value and the max value. The checks for value validity are ineffective as the min/max values could change immediately after being checked, raising the risk of the min value being greater than the max value and causing invalid settings. This possible bug is found by an experimental static analysis tool developed by our team, BassCheck[1]. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 5.17. To resolve this issue, it is suggested to encompass the validity checks within the locked sections in both set_min and set_max funcs. The modification ensures that the validation of 'val' against the current min/max values is atomic, thus maintaining the integrity of the settings. With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the lack of associated hardware, we cannot test the patch in runtime testing, and just verify it according to the code logic. [1] https://sites.google.com/view/basscheck/ Fixes: 71c3b60ec6d28 ("Bluetooth: Move BR/EDR debugfs file creation ...") Cc: stable(a)vger.kernel.org Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- net/bluetooth/hci_debugfs.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c index 6b7741f6e95b..f032fdf8f481 100644 --- a/net/bluetooth/hci_debugfs.c +++ b/net/bluetooth/hci_debugfs.c @@ -566,11 +566,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(idle_timeout_fops, idle_timeout_get, static int sniff_min_interval_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val == 0 || val % 2 || val > hdev->sniff_max_interval) + + hci_dev_lock(hdev); + if (val == 0 || val % 2 || val > hdev->sniff_max_interval) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->sniff_min_interval = val; hci_dev_unlock(hdev); @@ -594,11 +596,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(sniff_min_interval_fops, sniff_min_interval_get, static int sniff_max_interval_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val == 0 || val % 2 || val < hdev->sniff_min_interval) + + hci_dev_lock(hdev); + if (val == 0 || val % 2 || val < hdev->sniff_min_interval) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->sniff_max_interval = val; hci_dev_unlock(hdev); -- 2.34.1

10 months

1
0
0 0

[PATCH] Bluetooth: Fix atomicity violation in {min,max}_key_size_set

by Gui-Dong Han

In min_key_size_set(): if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE) return -EINVAL; hci_dev_lock(hdev); hdev->le_min_key_size = val; hci_dev_unlock(hdev); In max_key_size_set(): if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size) return -EINVAL; hci_dev_lock(hdev); hdev->le_max_key_size = val; hci_dev_unlock(hdev); The atomicity violation occurs due to concurrent execution of set_min and set_max funcs which may lead to inconsistent reads and writes of the min value and the max value. The checks for value validity are ineffective as the min/max values could change immediately after being checked, raising the risk of the min value being greater than the max value and causing invalid settings. This possible bug is found by an experimental static analysis tool developed by our team, BassCheck[1]. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 5.17. To resolve this issue, it is suggested to encompass the validity checks within the locked sections in both set_min and set_max funcs. The modification ensures that the validation of 'val' against the current min/max values is atomic, thus maintaining the integrity of the settings. With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the lack of associated hardware, we cannot test the patch in runtime testing, and just verify it according to the code logic. [1] https://sites.google.com/view/basscheck/ Fixes: 18f81241b74fb ("Bluetooth: Move {min,max}_key_size debugfs ...") Cc: stable(a)vger.kernel.org Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- net/bluetooth/hci_debugfs.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c index 6b7741f6e95b..3ffbf3f25363 100644 --- a/net/bluetooth/hci_debugfs.c +++ b/net/bluetooth/hci_debugfs.c @@ -1045,11 +1045,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(adv_max_interval_fops, adv_max_interval_get, static int min_key_size_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE) + + hci_dev_lock(hdev); + if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->le_min_key_size = val; hci_dev_unlock(hdev); @@ -1073,11 +1075,13 @@ DEFINE_DEBUGFS_ATTRIBUTE(min_key_size_fops, min_key_size_get, static int max_key_size_set(void *data, u64 val) { struct hci_dev *hdev = data; - - if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size) + + hci_dev_lock(hdev); + if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size) { + hci_dev_unlock(hdev); return -EINVAL; + } - hci_dev_lock(hdev); hdev->le_max_key_size = val; hci_dev_unlock(hdev); -- 2.34.1

10 months

1
0
0 0

[PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure

by guoren＠kernel.org

From: Guo Ren <guoren(a)linux.alibaba.com> In COMPAT mode, the STACK_TOP is 0x80000000, but the TASK_SIZE is 0x7fff000. When the user stack is upon 0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32. Freeing unused kernel image (initmem) memory: 2236K Run /sbin/init as init process Starting init: /sbin/init exists but couldn't execute it (error -14) Run /etc/init as init process ... Cc: stable(a)vger.kernel.org Fixes: add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") Signed-off-by: Guo Ren <guoren(a)linux.alibaba.com> Signed-off-by: Guo Ren <guoren(a)kernel.org> --- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index ab00235b018f..74ffb2178f54 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte) #define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2) #ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL)) #define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64) #else -- 2.40.1

10 months

4
6
0 0

[PATCH v2] usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart

by Uttkarsh Aggarwal

Current implementation blocks the running operations when Plug-out and Plug-In is performed continuously, process gets stuck in dwc3_thread_interrupt(). Code Flow: CPU1 ->Gadget_start ->dwc3_interrupt ->dwc3_thread_interrupt ->dwc3_process_event_buf ->dwc3_process_event_entry ->dwc3_endpoint_interrupt ->dwc3_ep0_interrupt ->dwc3_ep0_inspect_setup ->dwc3_ep0_stall_and_restart By this time if pending_list is not empty, it will get the next request on the given list and calls dwc3_gadget_giveback which will unmap request and call its complete() callback to notify upper layers that it has completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET, whereas it should be -ESHUTDOWN based on condition if not dwc->connected is true. Cc: <stable(a)vger.kernel.org> Fixes: d742220b3577 ("usb: dwc3: ep0: giveback requests on stall_and_restart") Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa(a)quicinc.com> --- Changes in v2: Added dwc->connected check to set status either -ESHUTDOWN and -ECONNRESET in dwc3_gadget_giveback. Link to v1: https://lore.kernel.org/all/20231122091127.3636-1-quic_uaggarwa@quicinc.com… drivers/usb/dwc3/ep0.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index b94243237293..816b8eea73d6 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -238,7 +238,10 @@ void dwc3_ep0_stall_and_restart(struct dwc3 *dwc) struct dwc3_request *req; req = next_request(&dep->pending_list); - dwc3_gadget_giveback(dep, req, -ECONNRESET); + if (!dwc->connected) + dwc3_gadget_giveback(dep, req, -ESHUTDOWN); + else + dwc3_gadget_giveback(dep, req, -ECONNRESET); } dwc->eps[0]->trb_enqueue = 0; -- 2.17.1

10 months

1
0
0 0

[PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end

by guoren＠kernel.org

From: Guo Ren <guoren(a)linux.alibaba.com> When the task is in COMPAT mode, the arch_get_mmap_end should be 2GB, not TASK_SIZE_64. The TASK_SIZE has contained is_compat_mode() detection, so change the definition of STACK_TOP_MAX to TASK_SIZE directly. Cc: stable(a)vger.kernel.org Fixes: add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") Signed-off-by: Guo Ren <guoren(a)linux.alibaba.com> Signed-off-by: Guo Ren <guoren(a)kernel.org> --- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h index f19f861cda54..1f538fc4448d 100644 --- a/arch/riscv/include/asm/processor.h +++ b/arch/riscv/include/asm/processor.h @@ -16,15 +16,13 @@ #ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZE #define arch_get_mmap_end(addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \ -- 2.40.1

10 months

5
14
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023