public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Tmpfs and loop device don't get along
@ 2002-02-01 21:19 Andrew Tipton
  2002-02-02  9:48 ` Christoph Rohland
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Tipton @ 2002-02-01 21:19 UTC (permalink / raw)
  To: linux-kernel

If I have an image (initrd.img for example) located on a tmpfs filesystem,
when I attempt to mount it:

% mount -o loop /initrd.img /mnt
ioctl: LOOP_SET_FD: Invalid argument

After deciding that it was not due to lack of loop devices (/dev/loop0..7),
an unreadable file, and other common userspace causes,  I dug through the
kernel sources.   When calling LOOP_SET_FD, the single argument is the
filedescriptor of the file (/initrd.img).  The loop_set_fd function (in
drivers/block/loop.c) first gets the inode entry for the file, and then the
address_space_operations struct for that inode.  If there is no readpage
function in that struct, loop_set_fd fails with EINVAL.  The reason for this
check is "if we can't read - sorry" -- apparently testing to see if it's
possible to read from the file/filesystem?

In the tmpfs source (mm/shmem.c), the address_space_operations struct for
this filesystem is defined.  The struct (shmem_aops) is defined statically,
and the only member is writepage.  readpage is missing, causing a guaranteed
failure in loop_set_fd.

Something smells wrong here (why does loop_set_fd care about
address_space_operations, and not file_operations?  it only needs access to
the file....), but I don't know enough about the internal workings of the
page cache/vfs/etc to do much about it.

What is the best way to fix this short-term?  I could bypass the readpage
check in loop_set_fd, or I could add a dummy readpage entry to the
address_space_operations struct for tmpfs.  Would either of these have
serious repercussions?

I'm not subscribed to the linux-kernel mailing list, so I would appreciate
it if you could CC all replies to me as well.

Thanks,
Andrew Tipton
Cadre5, LLC



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Tmpfs and loop device don't get along
  2002-02-01 21:19 Tmpfs and loop device don't get along Andrew Tipton
@ 2002-02-02  9:48 ` Christoph Rohland
  0 siblings, 0 replies; 2+ messages in thread
From: Christoph Rohland @ 2002-02-02  9:48 UTC (permalink / raw)
  To: Andrew Tipton; +Cc: linux-kernel

Hi Andrew,

On Fri, 1 Feb 2002, Andrew Tipton wrote:
> If I have an image (initrd.img for example) located on a tmpfs
> filesystem, when I attempt to mount it:
> 
> % mount -o loop /initrd.img /mnt
> ioctl: LOOP_SET_FD: Invalid argument

In the latest 2.4 sources you will find a file
Documentation/filesystems/tmpfs.txt which describes this problem.

> What is the best way to fix this short-term?  I could bypass the
> readpage check in loop_set_fd, or I could add a dummy readpage entry
> to the address_space_operations struct for tmpfs.  Would either of
> these have serious repercussions?

I do not see an easy and clean way so far. The check for readpage is
definitely needed. loop.c does rely on generic_file_{read,write} and
not on the files read and write operations. So IMHO the cleanest way
is to provide readpage et.al. in shmem.c and use generic_file_{read,write}
instead of specialized shmem_{read,write} functions. Unfortunately
this would mean a nontrivial change to the readpage semantics.

Greetings
		Christoph



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-02-03 11:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-01 21:19 Tmpfs and loop device don't get along Andrew Tipton
2002-02-02  9:48 ` Christoph Rohland

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox