LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

Chris Samuel

unread,

Jan 24, 2011, 7:30:02 PM1/24/11

to

/*
* CC'd to linux-kernel in case they have any feedback on this.
*
* Long thread, trying to work out why mkfs.btrfs failed to
* make a filesystem on an encrypted loopback mount called
* /dev/loop2. Cause turned out to be mkfs.btrfs calling
* LOOP_GET_STATUS to find out if the block device was mounted
* and getting a truncated device name back and so it later
* fails when lstat() is called on the truncated device path.
*
* The long device name for the encrypted loopback mount was
* because /dev/disk/by-id/$ID was used when Felix created it
* to cope with devices moving around.
*/

On 25/01/11 00:01, Felix Blanke wrote:

> you were talking about the LOOP_GET_STATUS function. I'm not
> quite sure where does it came from. Is it part of the kernel?
> Or does it come from the util-linux package?

It's in the kernel, and there is both LOOP_GET_STATUS (old
implementation) and LOOP_GET_STATUS64 (new implementation).

They return structures called loop_info and loop_info64
respectively and both are defined in include/linux/loop.h .

Sadly in both cases the lengths of paths are defined to be
LO_NAME_SIZE which is currently 64 and hence either
implementation will cause the problematic:

lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)

I've CC'd this to the LKML in case they have any feedback on
this apparent problem with the API.

cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Petr Uzel

unread,

Feb 10, 2011, 7:30:03 AM2/10/11

to

Since 2.6.37, you can get full path to the backing file from sys:
cat /sys/block/loopX/loop/backing_file

See
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-07/msg10996.html

HTH,

Petr

--
Petr Uzel
IRC: ptr_uzl @ freenode

Felix Blanke

unread,

Feb 11, 2011, 8:10:02 AM2/11/11

to

Hi,

are you sure that patch is in the kernel?

I'm using 2.6.37 and don't have those attribues in my /sys.

Felix

On 10. February 2011 - 13:29, Petr Uzel wrote:
> Date: Thu, 10 Feb 2011 13:29:27 +0100
> From: Petr Uzel <petr...@suse.cz>
> To: Chris Samuel <ch...@csamuel.org>
> Cc: Felix Blanke <felix...@gmail.com>, krei...@inwind.it, Hugo Mills
> <hugo...@carfax.org.uk>, linux...@vger.kernel.org, Linux Kernel
> <linux-...@vger.kernel.org>
> Subject: Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re:
> Bug in mkfs.btrfs?!)
> Mail-Followup-To: Chris Samuel <ch...@csamuel.org>, Felix Blanke
> <felix...@gmail.com>, krei...@inwind.it, Hugo Mills
> <hugo...@carfax.org.uk>, linux...@vger.kernel.org, Linux Kernel
> <linux-...@vger.kernel.org>

---end quoted text---

Milan Broz

unread,

Feb 11, 2011, 2:00:02 PM2/11/11

to

On 02/11/2011 02:04 PM, Felix Blanke wrote:
> I'm using 2.6.37 and don't have those attribues in my /sys.

These attributes are there only when the loop device is configured,
IOW when backing file is attached.

Milan

Milan Broz

unread,

Feb 11, 2011, 2:40:02 PM2/11/11

to

On 02/11/2011 08:23 PM, Felix Blanke wrote:
> What do you mean with "configured"?
>
> I'm using loop devices with loop aes, and I've looked into /sys for a device which is actually in use.

Ehm. It is really Loop-AES?

Then ask author to backport it there, Loop-AES is not mainline code.
He usually replaces the whole upstream loop implementation with old patched version.

Felix Blanke

unread,

Feb 11, 2011, 2:50:01 PM2/11/11

to

Yeah, for me its loop-aes.
Ah ok, didn't knew that it replaces that whole loop thing :)

Felix