Forwarded to dm-devel. Problem is a NULL pointer dereference in
kcryptd_io_read, which is triggered when mounting logfs. If someone
with device mapper knowledge could have a look, that would be useful.
On Wed, 14 September 2011 20:24:25 +0200, Jörn Engel wrote:
>
> Ok, I can reliably reproduce the problem with the following, based on
> your description:
>
> truncate -s 0 foo
> truncate -s 1G foo
> losetup -v -f foo
> cryptsetup luksFormat /dev/loop0
> cryptsetup luksOpen /dev/loop0 foo
> pvcreate /dev/mapper/foo
> vgcreate our_volume /dev/mapper/foo
> lvcreate -L 128M -n logfstest our_volume
> yes yes | mklogfs /dev/mapper/our_volume-logfstest
> mount /dev/mapper/our_volume-logfstest /mnt/
>
> It is a bit annoying that cryptsetup cannot easily be scripted. Oh
> well! Problem is indeed with the memcpy, except that
> bio_iovec(base_bio) is NULL, not clone->bi_io_vec. I have added this
> line in a bunch of places to get a better idea.
> printk("%p %p %p %s
", bio, bio->bi_io_vec, bio_iovec(bio), __func__);
>
> ffff88023424fc18 ffff88023424fca8 ffff88023424fca8 sync_request
> ffff88023424fc18 ffff88023424fca8 ffff88023424fca8 dm_request
> ffff88023424fc18 ffff88023424fca8 ffff88023424fca8 _dm_request
> ffff88023424fc18 ffff88023424fca8 ffff88023424fca8 __split_and_process_bio
> ffff880235a10d40 (null) (null) __map_bio
> ffff880235a10d40 (null) (null) dm_request
> ffff880235a10d40 (null) (null) _dm_request
> ffff880235a10d40 (null) (null) __split_and_process_bio
> ffff880235368780 (null) (null) __map_bio
> ffff880235368780 (null) (null) crypt_map
> ffff880235368780 (null) (null) kcryptd_io_read
>
> So __split_and_process_bio creates two new bios, both of which lack a
> bi_io_vec member and one of which gets passed to kcryptd_io_read
> eventually. Ho hum.
>
> My understanding of device mapper is not good enough yet to understand
> what is really going on here.
>
> Jörn
>
> --
> One of my most productive days was throwing away 1000 lines of code.
> -- Ken Thompson.
Jörn
--
In America you can have either a flimsy box banged together out of two
by fours and drywall, or a McMansion -- a flimsy box banged together
out of two by fours and drywall, but larger, more dramatic-looking,
and full of expensive fittings.
-- Paul Graham
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
09-14-2011, 07:01 PM
Witold Baryluk
logfs: kernel NULL dereference
On 09-14 20:34, Jörn Engel wrote:
> Forwarded to dm-devel. Problem is a NULL pointer dereference in
> kcryptd_io_read, which is triggered when mounting logfs. If someone
> with device mapper knowledge could have a look, that would be useful.
>
> On Wed, 14 September 2011 20:24:25 +0200, Jörn Engel wrote:
> >
> > Ok, I can reliably reproduce the problem with the following, based on
> > your description:
> >
> > truncate -s 0 foo
> > truncate -s 1G foo
> > losetup -v -f foo
> > cryptsetup luksFormat /dev/loop0
> > cryptsetup luksOpen /dev/loop0 foo
> > pvcreate /dev/mapper/foo
> > vgcreate our_volume /dev/mapper/foo
> > lvcreate -L 128M -n logfstest our_volume
> > yes yes | mklogfs /dev/mapper/our_volume-logfstest
> > mount /dev/mapper/our_volume-logfstest /mnt/
> >
On 09/14/2011 08:34 PM, Jörn Engel wrote:
> Forwarded to dm-devel. Problem is a NULL pointer dereference in
> kcryptd_io_read, which is triggered when mounting logfs. If someone
> with device mapper knowledge could have a look, that would be useful.
>
> On Wed, 14 September 2011 20:24:25 +0200, Jörn Engel wrote:
>>
>> Ok, I can reliably reproduce the problem with the following, based on
>> your description:
>>
>> truncate -s 0 foo
>> truncate -s 1G foo
>> losetup -v -f foo
>> cryptsetup luksFormat /dev/loop0
>> cryptsetup luksOpen /dev/loop0 foo
>> pvcreate /dev/mapper/foo
>> vgcreate our_volume /dev/mapper/foo
>> lvcreate -L 128M -n logfstest our_volume
>> yes yes | mklogfs /dev/mapper/our_volume-logfstest
>> mount /dev/mapper/our_volume-logfstest /mnt/
Which kernel version are you using?
>> It is a bit annoying that cryptsetup cannot easily be scripted.
It can be easily scripted. (In quiet mode it will not ask for YES response, add -q,
or just do "echo -n $PASSWORD | cryptsetup luksFormat ...")
Milan
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
09-15-2011, 02:52 PM
Jörn Engel
logfs: kernel NULL dereference
On Thu, 15 September 2011 16:27:52 +0200, Milan Broz wrote:
> On 09/14/2011 08:34 PM, Jörn Engel wrote:
> > Forwarded to dm-devel. Problem is a NULL pointer dereference in
> > kcryptd_io_read, which is triggered when mounting logfs. If someone
> > with device mapper knowledge could have a look, that would be useful.
> >
> > On Wed, 14 September 2011 20:24:25 +0200, Jörn Engel wrote:
> >>
> >> Ok, I can reliably reproduce the problem with the following, based on
> >> your description:
> >>
> >> truncate -s 0 foo
> >> truncate -s 1G foo
> >> losetup -v -f foo
> >> cryptsetup luksFormat /dev/loop0
> >> cryptsetup luksOpen /dev/loop0 foo
> >> pvcreate /dev/mapper/foo
> >> vgcreate our_volume /dev/mapper/foo
> >> lvcreate -L 128M -n logfstest our_volume
> >> yes yes | mklogfs /dev/mapper/our_volume-logfstest
> >> mount /dev/mapper/our_volume-logfstest /mnt/
>
> Which kernel version are you using?
Latest git - well, close to latest, given the current kernel.org trouble.
> >> It is a bit annoying that cryptsetup cannot easily be scripted.
>
> It can be easily scripted. (In quiet mode it will not ask for YES response, add -q,
> or just do "echo -n $PASSWORD | cryptsetup luksFormat ...")
Ok, I'll use that in the future. Thanks.
Jörn
--
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
logfs: kernel NULL dereference
