<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/md/md-bitmap.c, branch v6.18.43</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.43</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.43'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-24T14:16:32+00:00</updated>
<entry>
<title>md/raid1: honor REQ_NOWAIT when waiting for behind writes</title>
<updated>2026-07-24T14:16:32+00:00</updated>
<author>
<name>Abd-Alrhman Masalkhi</name>
<email>abd.masalkhi@gmail.com</email>
</author>
<published>2026-06-11T08:35:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c5384c40a4ceba5446fdabadca10bc25c53c6ec'/>
<id>urn:sha1:2c5384c40a4ceba5446fdabadca10bc25c53c6ec</id>
<content type='text'>
[ Upstream commit a286cb88ddb26c5f4377859d8e77233d9181eb82 ]

raid1 supports REQ_NOWAIT reads by avoiding waits in the barrier path
through wait_read_barrier(). However, a read can still block on a
WriteMostly device when the array uses a bitmap and there are
outstanding behind writes.

In that case raid1 unconditionally calls wait_behind_writes(), which
may sleep until all behind writes complete. As a result, a REQ_NOWAIT
read can block despite the caller explicitly requesting non-blocking
behavior.

This ensures that raid1 consistently honors REQ_NOWAIT reads across all
paths that may otherwise wait for behind writes.

Fixes: 5aa705039c4f ("md: raid1 add nowait support")
Signed-off-by: Abd-Alrhman Masalkhi &lt;abd.masalkhi@gmail.com&gt;
Link: https://patch.msgid.link/20260611083514.754922-1-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai &lt;yukuai@fygo.io&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: merge mddev serialize_policy into mddev_flags</title>
<updated>2026-07-24T14:16:32+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai@fnnas.com</email>
</author>
<published>2026-01-14T17:12:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=119903c3208304aba590ddcfb7cbc87fe0a321c0'/>
<id>urn:sha1:119903c3208304aba590ddcfb7cbc87fe0a321c0</id>
<content type='text'>
[ Upstream commit 10787568cc1f3f80afc510b2728751989dfa0ae6 ]

There is not need to use a separate field in struct mddev, there are no
functional changes.

Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-5-yukuai@fnnas.com
Signed-off-by: Yu Kuai &lt;yukuai@fnnas.com&gt;
Reviewed-by: Li Nan &lt;linan122@huawei.com&gt;
Stable-dep-of: a286cb88ddb2 ("md/raid1: honor REQ_NOWAIT when waiting for behind writes")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/md-bitmap: add a none backend for bitmap grow</title>
<updated>2026-05-23T11:07:10+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai@fnnas.com</email>
</author>
<published>2026-04-25T02:46:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f5bca930f8d57725b3856eea80327b182869a3b'/>
<id>urn:sha1:0f5bca930f8d57725b3856eea80327b182869a3b</id>
<content type='text'>
[ Upstream commit f2926a533d03fe70d753b512b713e06a2aa174af ]

Add a real none bitmap backend that exposes the common bitmap sysfs
group and use it to keep bitmap/location available when an array has no
bitmap.

Then switch the bitmap location sysfs path to move only between none
and the classic bitmap backend, using the no-sysfs bitmap helpers while
merging or unmerging the internal bitmap sysfs group.

This restores mdadm --grow bitmap addition through bitmap/location.

Fixes: fb8cc3b0d9db ("md/md-bitmap: delay registration of bitmap_ops until creating bitmap")
Reviewed-by: Su Yue &lt;glass.su@suse.com&gt;
Link: https://lore.kernel.org/r/20260425024615.1696892-4-yukuai@fnnas.com
Signed-off-by: Yu Kuai &lt;yukuai@fnnas.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/md-bitmap: split bitmap sysfs groups</title>
<updated>2026-05-23T11:07:10+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai@fnnas.com</email>
</author>
<published>2026-04-25T02:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7035caaa1b6f9344824060d4435d8a194195187e'/>
<id>urn:sha1:7035caaa1b6f9344824060d4435d8a194195187e</id>
<content type='text'>
[ Upstream commit aba3d6d6cb55c6e1116d1215140559dd7ecdf9a9 ]

Split the classic bitmap sysfs files into a common bitmap group with
the location attribute and a separate internal bitmap group for the
remaining files.

At the same time, convert bitmap operations from a single sysfs group
to a sysfs group array so backends can share part of their sysfs
layout while adding backend-specific attributes separately.

Switch the bitmap sysfs helpers to use sysfs_update_groups() for the
add and update path, and remove groups in reverse order so shared named
groups are unmerged before the last group removes the directory.

Also make bitmap operation lookup depend only on the currently selected
bitmap id matching the installed backend. This prepares the lookup path
for a later registered none backend.

Reviewed-by: Su Yue &lt;glass.su@suse.com&gt;
Link: https://lore.kernel.org/r/20260425024615.1696892-3-yukuai@fnnas.com
Signed-off-by: Yu Kuai &lt;yukuai@fnnas.com&gt;
Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/bitmap: fix GPF in write_page caused by resize race</title>
<updated>2026-03-04T12:21:16+00:00</updated>
<author>
<name>Jack Wang</name>
<email>jinpu.wang@ionos.com</email>
</author>
<published>2026-01-20T10:24:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a6f8cd28bb9bb6ed86a6df19331fb08016dee7f'/>
<id>urn:sha1:9a6f8cd28bb9bb6ed86a6df19331fb08016dee7f</id>
<content type='text'>
[ Upstream commit 46ef85f854dfa9d5226b3c1c46493d79556c9589 ]

A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]

This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap-&gt;storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.

Fix by holding `mddev-&gt;bitmap_info.mutex` during the bitmap update.

Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
Cc: stable@vger.kernel.org
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Signed-off-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: Yu Kuai &lt;yukuai@fnnas.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/md-llbitmap: introduce new lockless bitmap</title>
<updated>2025-09-06T09:27:51+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2025-08-29T08:04:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ab829f1971dc99f2aac10846c378e67fc875abc'/>
<id>urn:sha1:5ab829f1971dc99f2aac10846c378e67fc875abc</id>
<content type='text'>
Redundant data is used to enhance data fault tolerance, and the storage
method for redundant data vary depending on the RAID levels. And it's
important to maintain the consistency of redundant data.

Bitmap is used to record which data blocks have been synchronized and which
ones need to be resynchronized or recovered. Each bit in the bitmap
represents a segment of data in the array. When a bit is set, it indicates
that the multiple redundant copies of that data segment may not be
consistent. Data synchronization can be performed based on the bitmap after
power failure or readding a disk. If there is no bitmap, a full disk
synchronization is required.

Due to known performance issues with md-bitmap and the unreasonable
implementations:

 - self-managed IO submitting like filemap_write_page();
 - global spin_lock

I have decided not to continue optimizing based on the current bitmap
implementation, this new bitmap is invented without locking from IO fast
path and can be used with fast disks.

For designs and details, see the comments in drivers/md-llbitmap.c.

Link: https://lore.kernel.org/linux-raid/20250829080426.1441678-12-yukuai1@huaweicloud.com
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Reviewed-by: Li Nan &lt;linan122@huawei.com&gt;
</content>
</entry>
<entry>
<title>md/md-bitmap: support discard for bitmap ops</title>
<updated>2025-09-06T09:18:19+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2025-08-29T08:04:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac9dad8faaa7b2a7c7c6de0017f2d7d54525d33c'/>
<id>urn:sha1:ac9dad8faaa7b2a7c7c6de0017f2d7d54525d33c</id>
<content type='text'>
Use two new methods {start, end}_discard in bitmap_ops and a new field 'rw'
in struct md_io_clone to handle discard IO, prepare to support new md
bitmap.

Since all bitmap functions to hanlde write IO are the same, also add
typedef to make code cleaner.

Link: https://lore.kernel.org/linux-raid/20250829080426.1441678-4-yukuai1@huaweicloud.com
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Reviewed-by: Xiao Ni &lt;xni@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Li Nan &lt;linan122@huawei.com&gt;
</content>
</entry>
<entry>
<title>md: add a new parameter 'offset' to md_super_write()</title>
<updated>2025-09-06T09:17:26+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2025-08-29T08:04:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d01acbce391767318c94fb1f6d648cfabb428f9d'/>
<id>urn:sha1:d01acbce391767318c94fb1f6d648cfabb428f9d</id>
<content type='text'>
The parameter is always set to 0 for now, following patches will use
this helper to write llbitmap to underlying disks, allow writing
dirty sectors instead of the whole page.

Also rename md_super_write to md_write_metadata since there is nothing
super-block specific.

Link: https://lore.kernel.org/linux-raid/20250829080426.1441678-2-yukuai1@huaweicloud.com
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Reviewed-by: Xiao Ni &lt;xni@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Li Nan &lt;linan122@huawei.com&gt;
</content>
</entry>
<entry>
<title>md/md-bitmap: introduce CONFIG_MD_BITMAP</title>
<updated>2025-09-06T09:12:22+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2025-07-07T01:27:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c27474ac1d4609af3c1c38ccac252c2575b47b9e'/>
<id>urn:sha1:c27474ac1d4609af3c1c38ccac252c2575b47b9e</id>
<content type='text'>
Now that all implementations are internal, it's sensible to add a config
option for md-bitmap, and it's a good way for isolation.

Link: https://lore.kernel.org/linux-raid/20250707012711.376844-16-yukuai1@huaweicloud.com
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Reviewed-by: Xiao Ni &lt;xni@redhat.com&gt;
</content>
</entry>
<entry>
<title>md/raid1: check bitmap before behind write</title>
<updated>2025-09-06T09:11:58+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2025-07-07T01:27:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20cecae877a634ffc49b4cd7b0f6927209badbab'/>
<id>urn:sha1:20cecae877a634ffc49b4cd7b0f6927209badbab</id>
<content type='text'>
behind write rely on bitmap, because the number of IO are recorded in
bitmap-&gt;behind_writes, and callers rely on bitmap_wait_behind_writes()
to wait for IO to be done.

However, currently callers doesn't check if bitmap is enabeld before
calling into behind methods. Hence if behind write start without bitmap,
readers will not wait for slow write IO to be done and old data can be
read in some corner cases.

Link: https://lore.kernel.org/linux-raid/20250707012711.376844-10-yukuai1@huaweicloud.com
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Reviewed-by: Xiao Ni &lt;xni@redhat.com&gt;
</content>
</entry>
</feed>
