From: Zhihao Cheng <chengzhihao1@huawei.com> To: <richard@nod.at>, <miquel.raynal@bootlin.com>, <vigneshr@ti.com>, <mcoquelin.stm32@gmail.com>, <alexandre.torgue@foss.st.com> Cc: <linux-mtd@lists.infradead.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <bagasdotme@gmail.com> Subject: [PATCH v2 03/12] ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap Date: Mon, 28 Aug 2023 14:38:36 +0800 [thread overview] Message-ID: <20230828063845.3142561-4-chengzhihao1@huawei.com> (raw) In-Reply-To: <20230828063845.3142561-1-chengzhihao1@huawei.com> Function ubi_update_fastmap could be called in IO context, for example: ubifs_writepage do_writepage ubifs_jnl_write_data write_head ubifs_wbuf_write_nolock ubifs_leb_write ubi_leb_write ubi_eba_write_leb try_write_vid_and_data ubi_wl_get_peb ubi_update_fastmap erase_block So it's better to allocate memory with GFP_NOFS mode, in case waiting page writeback(dead loop). Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> --- drivers/mtd/ubi/fastmap.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c index 05ecdc049343..d64bfb986d40 100644 --- a/drivers/mtd/ubi/fastmap.c +++ b/drivers/mtd/ubi/fastmap.c @@ -20,7 +20,7 @@ static inline unsigned long *init_seen(struct ubi_device *ubi) if (!ubi_dbg_chk_fastmap(ubi)) return NULL; - ret = bitmap_zalloc(ubi->peb_count, GFP_KERNEL); + ret = bitmap_zalloc(ubi->peb_count, GFP_NOFS); if (!ret) return ERR_PTR(-ENOMEM); @@ -105,7 +105,7 @@ static struct ubi_vid_io_buf *new_fm_vbuf(struct ubi_device *ubi, int vol_id) struct ubi_vid_io_buf *new; struct ubi_vid_hdr *vh; - new = ubi_alloc_vid_buf(ubi, GFP_KERNEL); + new = ubi_alloc_vid_buf(ubi, GFP_NOFS); if (!new) goto out; @@ -1403,7 +1403,7 @@ static int erase_block(struct ubi_device *ubi, struct ubi_wl_entry *e) struct ubi_ec_hdr *ec_hdr; long long ec = e->ec; - ec_hdr = kzalloc(ubi->ec_hdr_alsize, GFP_KERNEL); + ec_hdr = kzalloc(ubi->ec_hdr_alsize, GFP_NOFS); if (!ec_hdr) return -ENOMEM; @@ -1459,7 +1459,7 @@ static int invalidate_fastmap(struct ubi_device *ubi) ubi->fm = NULL; ret = -ENOMEM; - fm = kzalloc(sizeof(*fm), GFP_KERNEL); + fm = kzalloc(sizeof(*fm), GFP_NOFS); if (!fm) goto out; @@ -1548,7 +1548,7 @@ int ubi_update_fastmap(struct ubi_device *ubi) return 0; } - new_fm = kzalloc(sizeof(*new_fm), GFP_KERNEL); + new_fm = kzalloc(sizeof(*new_fm), GFP_NOFS); if (!new_fm) { up_write(&ubi->fm_eba_sem); up_write(&ubi->work_sem); -- 2.39.2 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Zhihao Cheng <chengzhihao1@huawei.com> To: <richard@nod.at>, <miquel.raynal@bootlin.com>, <vigneshr@ti.com>, <mcoquelin.stm32@gmail.com>, <alexandre.torgue@foss.st.com> Cc: <linux-mtd@lists.infradead.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <bagasdotme@gmail.com> Subject: [PATCH v2 03/12] ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap Date: Mon, 28 Aug 2023 14:38:36 +0800 [thread overview] Message-ID: <20230828063845.3142561-4-chengzhihao1@huawei.com> (raw) In-Reply-To: <20230828063845.3142561-1-chengzhihao1@huawei.com> Function ubi_update_fastmap could be called in IO context, for example: ubifs_writepage do_writepage ubifs_jnl_write_data write_head ubifs_wbuf_write_nolock ubifs_leb_write ubi_leb_write ubi_eba_write_leb try_write_vid_and_data ubi_wl_get_peb ubi_update_fastmap erase_block So it's better to allocate memory with GFP_NOFS mode, in case waiting page writeback(dead loop). Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> --- drivers/mtd/ubi/fastmap.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c index 05ecdc049343..d64bfb986d40 100644 --- a/drivers/mtd/ubi/fastmap.c +++ b/drivers/mtd/ubi/fastmap.c @@ -20,7 +20,7 @@ static inline unsigned long *init_seen(struct ubi_device *ubi) if (!ubi_dbg_chk_fastmap(ubi)) return NULL; - ret = bitmap_zalloc(ubi->peb_count, GFP_KERNEL); + ret = bitmap_zalloc(ubi->peb_count, GFP_NOFS); if (!ret) return ERR_PTR(-ENOMEM); @@ -105,7 +105,7 @@ static struct ubi_vid_io_buf *new_fm_vbuf(struct ubi_device *ubi, int vol_id) struct ubi_vid_io_buf *new; struct ubi_vid_hdr *vh; - new = ubi_alloc_vid_buf(ubi, GFP_KERNEL); + new = ubi_alloc_vid_buf(ubi, GFP_NOFS); if (!new) goto out; @@ -1403,7 +1403,7 @@ static int erase_block(struct ubi_device *ubi, struct ubi_wl_entry *e) struct ubi_ec_hdr *ec_hdr; long long ec = e->ec; - ec_hdr = kzalloc(ubi->ec_hdr_alsize, GFP_KERNEL); + ec_hdr = kzalloc(ubi->ec_hdr_alsize, GFP_NOFS); if (!ec_hdr) return -ENOMEM; @@ -1459,7 +1459,7 @@ static int invalidate_fastmap(struct ubi_device *ubi) ubi->fm = NULL; ret = -ENOMEM; - fm = kzalloc(sizeof(*fm), GFP_KERNEL); + fm = kzalloc(sizeof(*fm), GFP_NOFS); if (!fm) goto out; @@ -1548,7 +1548,7 @@ int ubi_update_fastmap(struct ubi_device *ubi) return 0; } - new_fm = kzalloc(sizeof(*new_fm), GFP_KERNEL); + new_fm = kzalloc(sizeof(*new_fm), GFP_NOFS); if (!new_fm) { up_write(&ubi->fm_eba_sem); up_write(&ubi->work_sem); -- 2.39.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-08-28 6:44 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-28 6:38 [PATCH v2 00/12] ubi: fastmap: Fix a series of wear leveling problems Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 01/12] ubi: fastmap: Fix missed ec updating after erasing old fastmap data block Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 02/12] ubi: fastmap: erase_block: Get erase counter from wl_entry rather than flash Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng [this message] 2023-08-28 6:38 ` [PATCH v2 03/12] ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 04/12] ubi: Replace erase_block() with sync_erase() Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 05/12] ubi: fastmap: Use free pebs reserved for bad block handling Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 06/12] ubi: fastmap: Wait until there are enough free PEBs before filling pools Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 07/12] ubi: fastmap: Remove unneeded break condition while " Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 08/12] ubi: fastmap: may_reserve_for_fm: Don't reserve PEB if fm_anchor exists Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 09/12] ubi: fastmap: Get wl PEB even ec beyonds the 'max' if free PEBs are run out Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 10/12] ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 11/12] ubi: fastmap: Add module parameter to control reserving filling pool PEBs Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-08-28 6:38 ` [PATCH v2 12/12] ubi: fastmap: Add control in 'UBI_IOCATT' ioctl to reserve PEBs for filling pools Zhihao Cheng 2023-08-28 6:38 ` Zhihao Cheng 2023-10-12 2:57 ` [PATCH v2 00/12] ubi: fastmap: Fix a series of wear leveling problems Zhihao Cheng 2023-10-12 2:57 ` Zhihao Cheng 2023-10-15 19:34 ` Richard Weinberger 2023-10-15 19:34 ` Richard Weinberger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230828063845.3142561-4-chengzhihao1@huawei.com \ --to=chengzhihao1@huawei.com \ --cc=alexandre.torgue@foss.st.com \ --cc=bagasdotme@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=mcoquelin.stm32@gmail.com \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.