All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Samuel <chris@csamuel.org>
To: Felix Blanke <felixblanke@gmail.com>
Cc: kreijack@inwind.it, Hugo Mills <hugo-lkml@carfax.org.uk>,
	linux-btrfs@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)
Date: Tue, 25 Jan 2011 11:15:11 +1100	[thread overview]
Message-ID: <4D3E160F.4050006@csamuel.org> (raw)
In-Reply-To: <20110124130104.GA7354@scooter>

/*
 * 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

  parent reply	other threads:[~2011-01-25  0:15 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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:45     ` Hugo Mills
2011-01-22 15:56     ` Felix Blanke
2011-01-22 22:54       ` Chris Samuel
2011-01-22 23:03         ` Felix Blanke
2011-01-23 18:18       ` Hugo Mills
2011-01-23 22:02         ` Goffredo Baroncelli
2011-01-23 23:15           ` Felix Blanke
2011-01-24  7:42             ` Helmut Hullen
2011-01-24  9:41               ` Felix Blanke
2011-01-23 23:27           ` Hugo Mills
2011-01-23 23:58             ` Felix Blanke
2011-01-24  1:53               ` Fajar A. Nugraha
2011-01-24  9:38                 ` Felix Blanke
2011-01-24 13:01           ` Felix Blanke
2011-01-24 13:13             ` Hugo Mills
2011-01-24 13:53               ` Felix Blanke
2011-01-24 14:29                 ` Hugo Mills
2011-01-24 14:34                   ` Hugo Mills
2011-01-24 14:44                     ` Felix Blanke
2011-01-24 16:52                       ` Felix Blanke
2011-01-24 17:00                         ` Hugo Mills
2011-01-24 21:04                           ` Felix Blanke
2011-01-24 21:14                             ` Felix Blanke
2011-01-24 14:35                   ` Felix Blanke
2011-01-25  0:15             ` Chris Samuel [this message]
2011-02-10 12:29               ` LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!) Petr Uzel
2011-02-11 13:04                 ` Felix Blanke
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
2011-01-26 22:25 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=4D3E160F.4050006@csamuel.org \
    --to=chris@csamuel.org \
    --cc=felixblanke@gmail.com \
    --cc=hugo-lkml@carfax.org.uk \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.