[lkml]   [2002]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Loop devices under NTFS
On Tue, Aug 27, 2002 at 06:53:19AM -0700, Adam J. Richter wrote:
> Why?
> According to linux-2.5.31/Documentation/Locking,
> "->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
> may be called from the request handler (/dev/loop)."

Just because it's present in current code it doesn't mean it's right.
Calling aops directly from generic code is a layering violation and
it will not survive 2.5.

> Using the page cache in loop.c saves a copy when there is a
> data transformation (such as encryption) involved, and that can be
> important for reducing the cost of privacy.

Separating a stackalbe encryption block device from the loop driver is
a good idea. The current loop code is a horrible mess because it tries
to do the job of three drivers in one.

> >Depending on the filesystem implementation _anything_ may happen.
> >With current intree filesystems the only real life problem is that
> >it doesn't work on certain filesystems.
> Sorry for repeating myself here: If you're referring to the
> stock loop.c not working with tmpfs because tmpfs lacks
> {prepare,commit}_write which my patch works around (based on Jari's
> patch before mine, and a patch by Andrew Morton as well). I have yet
> to hear a clear reason why any writable plain file on any given file
> system could not have {prepare,commit}_write operations available.

No, tmpfs also does not use generic_file_read but a sligh variation,
calling do_generic_file_read on tmpfs inodes will not always works as
expected. Don't do it.

> Please come up with a clear example. I'm not asking you for a
> test case that can produce it, just some narrative of the problem
> occurring.

loop on nfs, do_generic_file_read is called without the needed
nfs_revalidate_inode, thus i_size is outdated, and loop might happily
read out of the filesize.

> I am aware that you can get races if someone mounts a loop
> device while accessing the underlying file by some other mechanism,
> but I believe that the only case where that would be done in practice
> is to change the encryption of a device, and, because of the read and
> write patterns involved in that, it should not be a problem.

This is true for filesystems like nfs (above) that only revalidate and then
call generic_file_read. For totally different implementations anything can
happen. Even if it mostly works it's not the kind of design we want to have
in the kernel.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.037 / U:1.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site