All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <dominique.martinet@atmark-techno.com>
To: Richard Weinberger <richard@nod.at>
Cc: stable <stable@vger.kernel.org>,
	chengzhihao1 <chengzhihao1@huawei.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Cheng Ming Lin <chengminglin@mxic.com.tw>,
	Liyuan Pang <pangliyuan1@huawei.com>
Subject: Re: [PATCH 0/2] Backport fixes for UBI
Date: Thu, 20 Aug 2026 09:57:27 +0900	[thread overview]
Message-ID: <aoZQ90HBGlM-SL8K@atmark-techno.com> (raw)
In-Reply-To: <1200997805.161072.1787136508436.JavaMail.zimbra@nod.at>

Richard Weinberger wrote on Wed, Aug 19, 2026 at 12:48:28PM +0200:
> While porting these back is not wrong, I have a hard time to see how the
> current stables rules apply here.

Thank you for looking into this!

I'm honestly fuzzy on stable backport "rules", but in practice I see all
sort of things get in (admitely sometimes new features/refactor just
because it makes an actual fix easier to backport, but also quite a few
leaks on failures like the second patch and other general improvements),
so after noticing someone else submitted 6.12 contiguous read
improvements recently[1] so I assumed such backports would be welcome...
But ultimately I think it's up to you, so happy to see the patches
dropped if you prefer.

[1] https://lore.kernel.org/r/20260811161342.533280-1-frieder@fris.de

> "mtd: ubi: skip programming unused bits in ubi headers" does not fix anything.
> It's a pure optimization for future flashes, UBI worked since ever without this
> change.

I might have misunderstood something about this patch, but while UBI
works fine I believe this would increase the longevity of more than just
"future flashes"

I've burned out 2 times 1MB (4 erase blocks) from the NAND I have on
hand (winbond W25N04LW) using either random data + erase (nandtest) or a
patched version writing zeroes + erase, and writing many zeroes failed
the erase blocks about 40-50% faster (85 thousands cycles vs 132
thousands until the first erase failure, 121/175 until erase stopped
working with many retries)

This obviously is a tiny sample size and not concrete proof, and this
patch won't have such a big impact because the area is small, but I
believe this patch will still improve the endurance a tiny bit for at
least our model, which was the motivation for me to pick this up.

Of course, there's also a chance that something breaks from it so I
can perfectly understand if you prefer not to backport it; you're in a
much better place than me to draw the line.


Thanks,
-- 
Dominique Martinet | Asmadeus

WARNING: multiple messages have this Message-ID (diff)
From: Dominique Martinet <dominique.martinet@atmark-techno.com>
To: Richard Weinberger <richard@nod.at>
Cc: stable <stable@vger.kernel.org>,
	chengzhihao1 <chengzhihao1@huawei.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Cheng Ming Lin <chengminglin@mxic.com.tw>,
	Liyuan Pang <pangliyuan1@huawei.com>
Subject: Re: [PATCH 0/2] Backport fixes for UBI
Date: Thu, 20 Aug 2026 09:57:27 +0900	[thread overview]
Message-ID: <aoZQ90HBGlM-SL8K@atmark-techno.com> (raw)
In-Reply-To: <1200997805.161072.1787136508436.JavaMail.zimbra@nod.at>

Richard Weinberger wrote on Wed, Aug 19, 2026 at 12:48:28PM +0200:
> While porting these back is not wrong, I have a hard time to see how the
> current stables rules apply here.

Thank you for looking into this!

I'm honestly fuzzy on stable backport "rules", but in practice I see all
sort of things get in (admitely sometimes new features/refactor just
because it makes an actual fix easier to backport, but also quite a few
leaks on failures like the second patch and other general improvements),
so after noticing someone else submitted 6.12 contiguous read
improvements recently[1] so I assumed such backports would be welcome...
But ultimately I think it's up to you, so happy to see the patches
dropped if you prefer.

[1] https://lore.kernel.org/r/20260811161342.533280-1-frieder@fris.de

> "mtd: ubi: skip programming unused bits in ubi headers" does not fix anything.
> It's a pure optimization for future flashes, UBI worked since ever without this
> change.

I might have misunderstood something about this patch, but while UBI
works fine I believe this would increase the longevity of more than just
"future flashes"

I've burned out 2 times 1MB (4 erase blocks) from the NAND I have on
hand (winbond W25N04LW) using either random data + erase (nandtest) or a
patched version writing zeroes + erase, and writing many zeroes failed
the erase blocks about 40-50% faster (85 thousands cycles vs 132
thousands until the first erase failure, 121/175 until erase stopped
working with many retries)

This obviously is a tiny sample size and not concrete proof, and this
patch won't have such a big impact because the area is small, but I
believe this patch will still improve the endurance a tiny bit for at
least our model, which was the motivation for me to pick this up.

Of course, there's also a chance that something breaks from it so I
can perfectly understand if you prefer not to backport it; you're in a
much better place than me to draw the line.


Thanks,
-- 
Dominique Martinet | Asmadeus

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-08-20  0:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18  2:09 [PATCH 0/2] Backport fixes for UBI Dominique Martinet
2026-08-18  2:09 ` Dominique Martinet
2026-08-18  2:09 ` [PATCH v6.12.y 1/2] mtd: ubi: skip programming unused bits in ubi headers Dominique Martinet
2026-08-18  2:09   ` Dominique Martinet
2026-08-18  4:46   ` Zhihao Cheng
2026-08-18  4:46     ` Zhihao Cheng
2026-08-18  2:09 ` [PATCH v6.12.y 2/2] ubi: fastmap: fix ubi->fm memory leak Dominique Martinet
2026-08-18  2:09   ` Dominique Martinet
2026-08-18  4:47   ` Zhihao Cheng
2026-08-18  4:47     ` Zhihao Cheng
2026-08-19  3:32 ` [PATCH 0/2] Backport fixes for UBI Sasha Levin
2026-08-19  3:32   ` Sasha Levin
2026-08-19 10:48 ` Richard Weinberger
2026-08-19 10:48   ` Richard Weinberger
2026-08-20  0:57   ` Dominique Martinet [this message]
2026-08-20  0:57     ` Dominique Martinet

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=aoZQ90HBGlM-SL8K@atmark-techno.com \
    --to=dominique.martinet@atmark-techno.com \
    --cc=chengminglin@mxic.com.tw \
    --cc=chengzhihao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=pangliyuan1@huawei.com \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    /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: link
Be 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.