From: Felix Blanke <felixblanke@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)
Date: Wed, 26 Jan 2011 23:25:18 +0100 [thread overview]
Message-ID: <20110126222518.GB2561@scooter> (raw)
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
Hi,
attached is the answer from Jari Ruusu, (one of?!) the main developer of loop-aes. It
seems that checking if a loop device is mounted following the link isn't the best
idea :)
I'll have time to look deeper into his example about the 14.02. I'll then try to fix
that issue in mkfs.btrfs. If someone wants to fix it earlier, do it :)
Regards,
Felix
[-- Attachment #2: Type: message/rfc822, Size: 5495 bytes --]
From: Jari Ruusu <jariruusu@users.sourceforge.net>
To: Felix Blanke <felixblanke@gmail.com>
Cc: linux-crypto@kernelnewbies.org
Subject: Re: Problem with losetup
Date: Wed, 26 Jan 2011 14:39:42 +0200
Message-ID: <4D40160E.605750DF@users.sourceforge.net>
First of all, I am not subscribed to linux-crypto@kernelnewbies.org mailing
list. But I do check web archive occasionally, at least for now. If you want
loop-AES maintainer to see your posts, please CC my @users.sourceforge.net
address, or linux-crypto@vger.kernel.org
Felix Blanke wrote:
> If I'm using the unpatched losetup (from util-linux-ng) and looping a
> device like
>
> /dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3
>
> it is using readlink to track down the link to e.g. /dev/sda3. But if
> I'm using the patched losetup I don't see any readlink in the strace.
> Because no readlink is used there is a problem with device names which
> have more then 64 characters (the field "lo_name" is an array of 64
> char). It is truncated like
>
> /dev/loop0: [0010]:6229
> (/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par)
> encryption=AES128
>
> That does make trouble with e.g. btrfs, because mkfs.btrfs uses the
> devicename provided by losetup to check if a device is mounted. That
> can't work with an incomplete devicename.
mkfs.btrfs authors goofed. Using truncated name is doomed to fail. Correct
way to check that is to compare loop backing file inode and device numbers
to inode and device numbers of supected file. Here is sample losetup output:
/dev/loop6: [0902]:209029 (/dev/md3) offset=4096 encryption=AES128 multi-key-v3
^^^^ ^^^^^^
device inode
Device number (0902) is hexadecimal. Inode number (209029) is decimal
number. /dev/md3 block special device node is present at mounted file system
on device 0x0902. Anything that symlinks or hardlinks to that inode 209029
on device 0x0902, is same file or device.
Even if losetup were to follow symlinks for that backing file name, symlink
destination would not necessarily be shorter. Although in your case it would
be shorter. Also, old versions of cryptoloop do not store the backing file
name at all. They use that same space for cipher algorithm name.
Below is source code for correct way for mkfs.btrfs to test loop backing
file status. Feel free to forward it to mkfs.btrfs authors.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
/* loop-backing-dev-check.c / (c) 2011 Jari Ruusu / GNU GPL */
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <linux/loop.h>
int loop_backing_dev_check(char *loopdev, char *suspect)
{
int fd, ret = 0;
struct stat statbuf;
struct loop_info64 info64;
struct loop_info info;
if(!loopdev || !*loopdev || !suspect || !*suspect) goto outret0;
if(stat(loopdev, &statbuf) || !S_ISBLK(statbuf.st_mode)) goto outret0;
if((statbuf.st_rdev & 0xfff00) != 0x700) goto outret0;
if(stat(suspect, &statbuf)) goto outret0;
if((fd = open(loopdev, O_RDONLY)) < 0) goto outret0;
if(!ioctl(fd, LOOP_GET_STATUS64, &info64)) {
if(statbuf.st_dev != info64.lo_device) goto closeret0;
if(statbuf.st_ino != info64.lo_inode) goto closeret0;
ret = 1; /* loop backing device/file is same as suspect */
} else if(!ioctl(fd, LOOP_GET_STATUS, &info)) {
if(statbuf.st_dev != info.lo_device) goto closeret0;
if(statbuf.st_ino != info.lo_inode) goto closeret0;
ret = 1; /* loop backing device/file is same as suspect */
}
closeret0:
close(fd);
outret0:
return ret;
}
/* usage: ./loop-backing-dev-check /dev/loop0 /dev/fd0 */
int main(int argc, char **argv)
{
if(argc != 3) exit(1);
if(loop_backing_dev_check(argv[1], argv[2])) {
printf("loop device %s is associated with %s\n", argv[1], argv[2]);
exit(0);
}
exit(1);
}
next reply other threads:[~2011-01-26 22:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-26 22:25 Felix Blanke [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-01-22 14:45 Bug in mkfs.btrfs?! Felix Blanke
2011-01-22 14:52 ` Felix Blanke
2011-01-22 15:11 ` Hugo Mills
2011-01-22 15:56 ` Felix Blanke
2011-01-23 18:18 ` Hugo Mills
2011-01-23 22:02 ` Goffredo Baroncelli
2011-01-24 13:01 ` Felix Blanke
2011-01-25 0:15 ` LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!) Chris Samuel
2011-02-10 12:29 ` Petr Uzel
2011-02-11 13:04 ` Felix Blanke
2011-02-11 18:59 ` Milan Broz
[not found] ` <AANLkTi=Arg-09F0DXsWNhsYgyPar=rKs7G_OQG2uMm4f@mail.gmail.com>
2011-02-11 19:31 ` Milan Broz
2011-02-11 19:41 ` Felix Blanke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110126222518.GB2561@scooter \
--to=felixblanke@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).