Hi,
I've hit a dm-integrity crash when re-extending dm-integrity device. The
trick is that underlying device needs to change its size as well.
There's reproducer attached which I have tested on top of scsi_debug
device but it's not limited to scsi_debug.
Tested kernel version: 5.17.0, My min
On Tue, 23 Mar 2021, Milan Broz wrote:
> > Do you need to bump the number of feature args supported (from 17 to
> > 18)?
Goo point. I've sent version 2 of the patch.
> And also update target minor version.
>
> I was just under the impression that we decided not to support such a
> flag (bec
On 23/03/2021 16:12, Mike Snitzer wrote:
> On Tue, Mar 23 2021 at 10:59am -0400,
> Mikulas Patocka wrote:
>
>> This patch adds a new flag "reset_recalculate" that will restart
>> recalculating from the beginning of the device. It can be used if we want
>> to change the hash function. Example:
>>
On Tue, Mar 23 2021 at 10:59am -0400,
Mikulas Patocka wrote:
> This patch adds a new flag "reset_recalculate" that will restart
> recalculating from the beginning of the device. It can be used if we want
> to change the hash function. Example:
>
> #!/bin/sh
> dmsetup remove_all
> rmmod brd
> set
On Tue, 12 Jan 2021, Mike Snitzer wrote:
> On Tue, Jan 12 2021 at 2:54pm -0500,
> Mikulas Patocka wrote:
>
> > Advance the maximum number of arguments to 15.
> >
> > Signed-off-by: Mikulas Patocka
> > Cc: sta...@vger.kernel.org # v4.19+
> >
> > ---
> > drivers/md/dm-integrity.c |2 +
On Tue, Jan 12 2021 at 2:54pm -0500,
Mikulas Patocka wrote:
> Advance the maximum number of arguments to 15.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org# v4.19+
>
> ---
> drivers/md/dm-integrity.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index:
On Fri, 8 Jan 2021, Mike Snitzer wrote:
> > > Seems like a pretty bad oversight... but shouldn't you also make sure to
> > > flush the data device _before_ the metadata is flushed?
> > >
> > > Mike
> >
> > I think, ordering is not a problem.
> >
> > A disk may flush its cache spontaneously a
On Fri, Jan 08 2021 at 11:12am -0500,
Mikulas Patocka wrote:
>
>
> On Mon, 4 Jan 2021, Mike Snitzer wrote:
>
> > On Sun, Dec 20 2020 at 8:02am -0500,
> > Lukas Straub wrote:
> >
> > > With an external metadata device, flush requests aren't passed down
> > > to the data device.
> > >
> > >
On Mon, 4 Jan 2021, Mike Snitzer wrote:
> On Sun, Dec 20 2020 at 8:02am -0500,
> Lukas Straub wrote:
>
> > With an external metadata device, flush requests aren't passed down
> > to the data device.
> >
> > Fix this by issuing flush in the right places: In integrity_commit
> > when not in j
On Sun, Dec 20 2020 at 8:02am -0500,
Lukas Straub wrote:
> With an external metadata device, flush requests aren't passed down
> to the data device.
>
> Fix this by issuing flush in the right places: In integrity_commit
> when not in journal mode, in do_journal_write after writing the
> content
On Wed, 22 Jul 2020, Mike Snitzer wrote:
> On Wed, Jul 22 2020 at 2:46pm -0400,
> Mikulas Patocka wrote:
>
> > Hi Mike
> >
> > Please submit this to Linus and to RHEL-8.
> >
> > Mikulas
> >
> >
> >
> > From: Mikulas Patocka
> >
> > The patch adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 br
On Wed, Jul 22 2020 at 2:46pm -0400,
Mikulas Patocka wrote:
> Hi Mike
>
> Please submit this to Linus and to RHEL-8.
>
> Mikulas
>
>
>
> From: Mikulas Patocka
>
> The patch adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 broke recalculation on
> dm-integrity. The patch replaces a private variabl
On Tue, Feb 25 2020 at 5:02pm -0500,
Christoph Hellwig wrote:
> On Tue, Feb 25, 2020 at 08:54:07PM +0100, Daniel Glöckner wrote:
> > bio_reset will reset too many fields. As you can see in the context of
> > the diff, dm-integrity expects f.ex. the values modified by bio_advance
> > to stay inta
On Mon, Jan 13, 2020 at 10:17 AM Piergiorgio Sartor
wrote:
>
> On Mon, Jan 13, 2020 at 10:11:00AM -0800, Song Liu wrote:
> > + dm-devel
> >
> > On Sun, Jan 12, 2020 at 5:43 AM Gandalf Corvotempesta
> > wrote:
> > >
> > > I'm testing dm-integrity.
> > > Simple question: when corrupted data are fou
On Mon, Jan 13, 2020 at 10:11:00AM -0800, Song Liu wrote:
> + dm-devel
>
> On Sun, Jan 12, 2020 at 5:43 AM Gandalf Corvotempesta
> wrote:
> >
> > I'm testing dm-integrity.
> > Simple question: when corrupted data are found, repair is done
> > immediately or on next scrub?
> >
> > This is what I h
+ dm-devel
On Sun, Jan 12, 2020 at 5:43 AM Gandalf Corvotempesta
wrote:
>
> I'm testing dm-integrity.
> Simple question: when corrupted data are found, repair is done
> immediately or on next scrub?
>
> This is what I have:
>
> [ 6727.395808] md: data-check of RAID array md0
> [ 6727.528589] devi
Il giorno lun 13 gen 2020 alle ore 19:58 Song Liu ha scritto:
> Right now, md_done_sync() doesn't really print any message. I think this is
> easy to add. However, md check/recovery is at block granularity, so we
> probably cannot print exact which sector got fixed.
Well, having the exact sector
On 5/22/19 12:07 AM, Mike Snitzer wrote:
> On Tue, May 21 2019 at 4:33pm -0400,
> Hans van Kranenburg wrote:
>
>> Hi,
>>
>> On 5/21/19 10:43 AM, Hans van Kranenburg wrote:
>>> Hi,
>>>
>>> I'm seeing the same lockup, also 4.19. This is mdadm RAID10 on top of 4x
>>> a partition with only dm-integr
On Tue, May 21 2019 at 4:33pm -0400,
Hans van Kranenburg wrote:
> Hi,
>
> On 5/21/19 10:43 AM, Hans van Kranenburg wrote:
> > Hi,
> >
> > I'm seeing the same lockup, also 4.19. This is mdadm RAID10 on top of 4x
> > a partition with only dm-integrity.
> >
> > It just happened out of the blue,
On Tue, May 07 2019 at 2:28pm -0400,
Mikulas Patocka wrote:
> When we use separate devices for data and metadata, dm-integrity would
> incorrectly calculate the size of the metadata device as if it had
> 512-byte block size - and it would refuse activation with larger block
> size and smaller me
Hi dm-devel list,
I have a question, or actually want to share a thought experiment about
using the stuff mentioned in the title of the post, and I'm looking for
feedback on it that either sounds like "Yes, you got it right, you can
do this." or "Nope, don't do this, you're missing the fact that X
On 17/10/2018 15:35, Horia Geanta wrote:
> On 9/21/2018 3:06 PM, Neil Armstrong wrote:
>> Hi,
>>
>> I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM
>> Hash functions enabled using the following command lines :
>>
>> Linux 4.14.71
>>
>> cryptsetup luksFormat /dev/mmcblk
On Wed, Oct 17, 2018 at 4:35 PM Horia Geanta wrote:
>
> On 9/21/2018 3:06 PM, Neil Armstrong wrote:
> > Hi,
> >
> > I recently configured dm-crypt + dm-integrity on an iMX6q platform with
> > CAAM Hash functions enabled using the following command lines :
> >
> > Linux 4.14.71
> >
> > cryptsetup
On 9/21/2018 3:06 PM, Neil Armstrong wrote:
> Hi,
>
> I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM
> Hash functions enabled using the following command lines :
>
> Linux 4.14.71
>
> cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2
> --i
Hi,
I recently configured dm-crypt + dm-integrity on an iMX6q platform with CAAM
Hash functions enabled using the following command lines :
Linux 4.14.71
cryptsetup luksFormat /dev/mmcblk1p3 --cipher aes-xts-plain64 --type luks2
--integrity hmac-sha256 --sector-size 512 --use-urandom
cryptsetu
On Wed, Jan 10 2018 at 9:32am -0500,
Mikulas Patocka wrote:
>
>
> On Wed, 27 Dec 2017, Herbert Xu wrote:
>
> > On Tue, Dec 26, 2017 at 02:21:53PM +0200, Gilad Ben-Yossef wrote:
> > >
> > > See how SKCIPHER_REQUEST_ON_STACK is being used with an asymmetric
> > > skcipher
> > > in drivers/md/
On Thu, Jul 27 2017 at 9:10am -0400,
Milan Broz wrote:
> On 07/21/2017 06:00 PM, Mikulas Patocka wrote:
> > This is a patch to count errors in dm-integrity - as Jon suggested.
> >
> > This patch changes dm-integrity so that it counts the number of checksum
> > failures and reports the counter i
On Thu, 20 Jul 2017, John Stoffel wrote:
> Mikulas> In the early days when I was programming, I was adding checks for
> NULL
> Mikulas> pointers "just in case - so that it doesn't crash". But these checks
> Mikulas> didn't make the code any more understandable - they made the code
> less
>
> "Mikulas" == Mikulas Patocka writes:
Mikulas> On Wed, 19 Jul 2017, John Stoffel wrote:
>> I'd like to argue that you should never use BUG_ON at all, esp since
>> if you have integrity running on just one critical device, but have
>> other devices that work just fine, bringing down the enti
On Thu, 20 Jul 2017, Mikulas Patocka wrote:
>
>
> On Wed, 19 Jul 2017, John Stoffel wrote:
>
> > I'd like to argue that you should never use BUG_ON at all, esp since
> > if you have integrity running on just one critical device, but have
> > other devices that work just fine, bringing down th
On Wed, 19 Jul 2017, John Stoffel wrote:
> I'd like to argue that you should never use BUG_ON at all, esp since
> if you have integrity running on just one critical device, but have
> other devices that work just fine, bringing down the entire system
> because you don't think things are ok is te
On Wed, 19 Jul 2017, Mike Snitzer wrote:
> On Wed, Jul 19 2017 at 2:39pm -0400,
> John Stoffel wrote:
>
> > > "Mikulas" == Mikulas Patocka writes:
> >
> > Mikulas> When using block size greater than 512 bytes, the dm-integrity
> > target
> > Mikulas> allocates journal space inefficient
> "Mike" == Mike Snitzer writes:
Mike> On Wed, Jul 19 2017 at 2:39pm -0400,
Mike> John Stoffel wrote:
>> > "Mikulas" == Mikulas Patocka writes:
>>
Mikulas> When using block size greater than 512 bytes, the dm-integrity target
Mikulas> allocates journal space inefficiently, it allocat
On Wed, Jul 19 2017 at 2:39pm -0400,
John Stoffel wrote:
> > "Mikulas" == Mikulas Patocka writes:
>
> Mikulas> When using block size greater than 512 bytes, the dm-integrity target
> Mikulas> allocates journal space inefficiently, it allocates one entry for
> each
> Mikulas> 512-byte chun
Hi
On Wed, 12 Jul 2017, Renesanso wrote:
> Hi. Please, give link to your blog.
>
> I succesfully create configuration for virtual machines (and it works
> fine), test force reboot many time (and machine have some problem with
> ACPI table, thats why SATA controller reset links for all disks (n
On 07/12/2017 08:36 PM, Renesanso wrote:
> I have other question: why you dont use AEAD idea from redhad for
> dm-crypt (cryptsetup, that works, as they present), that realise AES-GCM
> (as, example ZFS use)? Why do you want to merge dm-integrity and
> dm-crypt?
> https://mbroz.fedorapeople.org
I have other question: why you dont use AEAD idea from redhad for
dm-crypt (cryptsetup, that works, as they present), that realise AES-GCM
(as, example ZFS use)? Why do you want to merge dm-integrity and
dm-crypt?
https://mbroz.fedorapeople.org/talks/DevConf2017/devconf2017-aead.pdf
07.07.201
Hi.*Please, give link to your blog.*
I succesfully create configuration for virtual machines (and it works
fine), test force reboot many time (and machine have some problem with
ACPI table, thats why SATA controller reset links for all disks (now it
fixed), but only one disk is out from md-rai
1. And in this (
https://kernel.googlesource.com/pub/scm/linux/kernel/git/kasatkin/linux-digsig/+/2dfa67a1a4c049fd33fcc6abcb1c8ca57b17a268/Documentation/device-mapper/dm-integrity.txt
) implementation gives variant to use external device for metadata and
journal. It really affect perfomance, I t
On 07/05/2017 06:45 PM, Renesanso wrote:
> 1. And in this (
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kasatkin/linux-digsig/+/2dfa67a1a4c049fd33fcc6abcb1c8ca57b17a268/Documentation/device-mapper/dm-integrity.txt
>
> ) implementation gives variant to use external device for metad
On 07/03/2017 06:44 AM, Renesanso wrote:
> Hi for all.
>
> Dmitry Kasatkin's fork of linux.git write dm-integrity patch for linux
...
yes, unfortunately we named the target the same (and I realized it too late).
It is doing something similar but definitely it is not the same.
> I try to use dm
On Mon, Jun 19 2017 at 11:16am -0400,
Ondrej Kozina wrote:
> On 06/19/2017 04:20 PM, Mike Snitzer wrote:
> >
> >Looks like submit_flush_bio() is disabling/enabling interrupts from
> >interrupt context. Ondrej, does this patch fix the issue?
>
> I let it spin for 30 minutes on patched dm-integri
On 06/19/2017 04:20 PM, Mike Snitzer wrote:
Looks like submit_flush_bio() is disabling/enabling interrupts from
interrupt context. Ondrej, does this patch fix the issue?
I let it spin for 30 minutes on patched dm-integrity and everything
seems ok now. The moment I loaded back the old one it
On Mon, Jun 19 2017 at 8:11am -0400,
Ondrej Kozina wrote:
> same log again, hopefully prettier format. Sorry:
>
> [ 330.980914] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [ 330.980923] [ cut here ]
> [ 330.982627] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.
same log again, hopefully prettier format. Sorry:
[ 330.980914] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[ 330.980923] [ cut here ]
[ 330.982627] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2748
trace_hardirqs_on_caller+0x107/0x180
[ 330.984340] Modules li
Hi,
cryptsetup testsuite easily triggers following crash. I can provide more
info on demand, but currently most straightforward way to trigger it is:
1) checkout cryptsetup master branch
(https://gitlab.com/cryptsetup/cryptsetup.git)
2)./autogen.sh --disable-python --enable-integritysetup
3)
46 matches
Mail list logo
