On 9/9/25 4:22 PM, Ivan Abramov wrote:
The return values of VDO_ASSERT calls that validate metadata are not acted
upon.
Return UDS_CORRUPT_DATA in case of an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: a4eb7e255517 ("dm vdo: implement the volume index")
S
On 9/10/25 10:29 AM, Bart Van Assche wrote:
> On 9/9/25 5:53 PM, Damien Le Moal wrote:
>> On 9/10/25 3:26 AM, Bart Van Assche wrote:
>>> Splitting a bio into an empty flush bio and a non-flush data bio is
>>> only necessary if there are multiple underlying devices. Do not split
>>> REQ_PREFLUSH bio
On 9/9/25 5:53 PM, Damien Le Moal wrote:
On 9/10/25 3:26 AM, Bart Van Assche wrote:
Splitting a bio into an empty flush bio and a non-flush data bio is
only necessary if there are multiple underlying devices. Do not split
REQ_PREFLUSH bios if there is only one underlying device. This patch
prese
On 9/10/25 3:26 AM, Bart Van Assche wrote:
> Splitting a bio into an empty flush bio and a non-flush data bio is
> only necessary if there are multiple underlying devices. Do not split
> REQ_PREFLUSH bios if there is only one underlying device. This patch
> preserves the order of REQ_PREFLUSH write
Splitting a bio into an empty flush bio and a non-flush data bio is
only necessary if there are multiple underlying devices. Do not split
REQ_PREFLUSH bios if there is only one underlying device. This patch
preserves the order of REQ_PREFLUSH writes if there is only one
underlying device and if mul
Replace bvec_kmap_local with kmap_local_page - it will be needed for the
upcoming patches that make kmap_local_page optional, depending on whether
asynchronous hash interface is used or not.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-integrity.c | 13 ++---
1 file changed, 6 inse
The return values of VDO_ASSERT calls that validate metadata are not acted
upon.
Return UDS_CORRUPT_DATA in case of an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: a4eb7e255517 ("dm vdo: implement the volume index")
Signed-off-by: Ivan Abramov
---
v2: Change a
On 9/8/25 6:24 PM, Ivan Abramov wrote:
There's an incorrect VDO_ASSERT macro usage in
start_restoring volume_index() and start_restoring_volume_sub_index(),
since assert's return value is not used anywhere.
Thus, use VDO_ASSERT_LOG_ONLY macro in such cases.
Found by Linux Verification Center (l
On 9/9/25 2:58 PM, Matthew Sakai wrote:
On 9/8/25 6:24 PM, Ivan Abramov wrote:
There's an incorrect VDO_ASSERT macro usage in
start_restoring volume_index() and start_restoring_volume_sub_index(),
since assert's return value is not used anywhere.
Thus, use VDO_ASSERT_LOG_ONLY macro in such c
On Tue, 09 Sep 2025 15:37:09 +0100 Mikulas Patocka
wrote ---
>
>
> On Mon, 8 Sep 2025, Robert Beckett wrote:
>
> > Hi,
> >
> > While testing resiliency of encrypted swap using dmcrypt we encounter
> > easily reproducible deadlocks.
> > The setup is a simple 1GB encrypted s
On Mon, 8 Sep 2025, Robert Beckett wrote:
> Hi,
>
> While testing resiliency of encrypted swap using dmcrypt we encounter easily
> reproducible deadlocks.
> The setup is a simple 1GB encrypted swap file [1] with a little mem chewer
> program [2] to consume all ram.
>
> [1] Swap file setup
>
On 9/9/25 3:51 PM, Harald Freudenberger wrote:
On 2025-09-09 14:15, Milan Broz wrote:
On 9/9/25 1:50 PM, Ingo Franzki wrote:
On 09.09.2025 13:47, Milan Broz wrote:
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean
6.17.0-rc5 just
to verify that
On 2025-08-25 16:23, Mikulas Patocka wrote:
Hi
I'd like to ask about this condition in crypto_ahash_digest:
if (ahash_req_on_stack(req) && ahash_is_async(tfm))
return -EAGAIN;
Can it be removed? Or, is there some reason why you can't have
asynchronous requests on the sta
On 2025-09-09 14:15, Milan Broz wrote:
On 9/9/25 1:50 PM, Ingo Franzki wrote:
On 09.09.2025 13:47, Milan Broz wrote:
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean
6.17.0-rc5 just
to verify that the patches do not introduce the bug.
With yo
On 9/9/25 1:50 PM, Ingo Franzki wrote:
On 09.09.2025 13:47, Milan Broz wrote:
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
to verify that the patches do not introduce the bug.
With your patches reverted the combined mode fai
On 09.09.2025 14:15, Milan Broz wrote:
> On 9/9/25 1:50 PM, Ingo Franzki wrote:
>> On 09.09.2025 13:47, Milan Broz wrote:
>>> On 9/9/25 1:18 PM, Ingo Franzki wrote:
> Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
> to verify that the patches do not introduce the
On 09.09.2025 11:42, Mikulas Patocka wrote:
>
>
> On Tue, 9 Sep 2025, Ingo Franzki wrote:
>
>> However, combined encryption and integrity seems to have problems. Not
>> sure if this is related to your changes in dm-integrity, or if there is
>> still something missing in dm-crypt, or the interf
On Tue, 9 Sep 2025, Ingo Franzki wrote:
> However, combined encryption and integrity seems to have problems. Not
> sure if this is related to your changes in dm-integrity, or if there is
> still something missing in dm-crypt, or the interface between the two:
>
> I did:
>
> # cryptsetup luks
On Mon, 2025-09-08 at 14:34 -0400, Benjamin Marzinski wrote:
> On Fri, Sep 05, 2025 at 11:07:13PM +0200, Martin Wilck wrote:
> > Coverity scan defect #488155.
> >
>
> Your fix looks fine, but the code I see right above it isn't. We
> should
> not be returning a positive number here if things went
On 08.09.2025 15:16, Mikulas Patocka wrote:
> Hi
>
> These patches add asynchronous hash support to dm-integrity.
>
> Harald, please test them, I will commit them if they work for you.
>
> Mikulas
>
I have started to test your patches in top of 6.17.0-rc5.
I am testing 2 scenarios:
1.) plain d
20 matches
Mail list logo
