The pull request you sent on Fri, 22 Jan 2021 17:24:45 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> tags/for-5.11/dm-fixes-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fe75a21824e78405b8d812421974524092250c63
Thank you!
--
Hi Linus,
The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31:
Linux 5.11-rc4 (2021-01-17 16:37:05 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
tags/for-5.11/dm-fixes-2
for you to fetch
Fix the writeset tree equality test function to use the right value size
when comparing two btree values.
Fixes: eec40579d84873 ("dm: add era target")
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Nikos Tsironis
---
drivers/md/dm-era-target.c | 2 +-
1 file changed, 1 insertion(+), 1
Deallocate the memory allocated for the in-core bitsets when destroying
the target and in error paths.
Fixes: eec40579d84873 ("dm: add era target")
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Nikos Tsironis
---
drivers/md/dm-era-target.c | 6 ++
1 file changed, 6 insertions(+)
diff
While working on fixing the bugs that cause lost writes, for which I
have sent separate emails, I bumped into several other minor issues that
I fix in this patch set.
In particular, this series of commits introduces the following fixes:
1. Add explicit check that the data block size hasn't
dm-era doesn't support changing the data block size of existing devices,
so check explicitly that the requested block size for a new target
matches the one stored in the metadata.
Fixes: eec40579d84873 ("dm: add era target")
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Nikos Tsironis
---
The device metadata are resized in era_ctr(), so the metadata resize
operation in era_preresume() never runs.
Also, note, that if the operation did ever run it would deadlock, since
the worker has not been started at this point.
Fixes: eec40579d84873 ("dm: add era target")
Cc:
In case of devices with at most 64 blocks, the digestion of consecutive
eras uses the writeset of the first era as the writeset of all eras to
digest, leading to lost writes. That is, we lose the information about
what blocks were written during the affected eras.
The digestion code uses a
In case of devices with at most 64 blocks, the digestion of consecutive
eras uses the writeset of the first era as the writeset of all eras to
digest, leading to lost writes. That is, we lose the information about
what blocks were written during the affected eras.
The root cause of the bug is a
In case of a system crash, dm-era might fail to mark blocks as written
in its metadata, although the corresponding writes to these blocks were
passed down to the origin device and completed successfully.
Consider the following sequence of events:
1. We write to a block that has not been yet
Following a system crash, dm-era fails to recover the committed writeset
for the current era, leading to lost writes. That is, we lose the
information about what blocks were written during the affected era.
dm-era assumes that the writeset of the current era is archived when the
device is
In case of a system crash, dm-era might lose the information about
blocks written during the current era, although the corresponding writes
were passed down to the origin device and completed successfully.
There are two major, distinct bugs that can lead to lost writes:
1. dm-era doesn't
Hi, Mike,
I got "attempt to access beyond end of device
dm-0: rw=0, want=3129056, limit=2097152" error when I was reloading the
table of dm-0, while there's a background **direct** IO on dm-0 (no fs
on it, i.e., just raw device) meanwhile.
It seems that it fails bio_check_eod() in submit_bio().
IS_ENABLED(CONFIG_ENCRYPTED_KEYS) is true whether the option is built-in
or a module, so use it instead of #if defined checking for each
separately.
The other #if was to avoid a static function defined, but unused
warning. As we now always build the callsite when the function
is defined, we can
Commit 27f5411a718c ("dm crypt: support using encrypted keys") extended
dm-crypt to allow use of "encrypted" keys along with "user" and "logon".
Along the same lines, teach dm-crypt to support "trusted" keys as well.
Signed-off-by: Ahmad Fatoum
---
Unsure on whether target_type::version is
15 matches
Mail list logo
