linux-ext4 - Re: [PATCH RFC] Insure direct IO writes do not use the page cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6601abe90907310910n694c32dfob3e2a207b07333f4@mail.gmail.com>
Date:	Fri, 31 Jul 2009 09:10:20 -0700
From:	Curt Wohlgemuth <curtw@...gle.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] Insure direct IO writes do not use the page cache

Thanks to all for ideas and corrections for my original patch.  I'd like to
summarize the issues that I've seen raised:

1. Using blockdev_direct_IO_own_locking() as it stands, without additional
   locking in the ext4 code, is incorrect.

2. The conversion from uninit to initialized extents should be done in an IO
   completion handler.

3. When the uninit-to-init extents are converted, the handle must be marked
   as synchronous.

   But this will make DIO writes (to fallocated space) with a journal have
   bad performance.

4. Ted mentioned some optimizations possible for extent conversion (when the
   extent block isn't part of a transaction, and no new block is required).
   Jan says that verifying that the extent block is not part of a
   transaction can be difficult.

   Also we could increase the extent size that we're willing to zero out the
   data blocks for.

5. Aneesh mentioned that we could use extent tracking a la Chris Mason's
   patch for data=guarded (I confess, I haven't looked at this yet).

6. Jan's other thought is to use a new ext4_get_blocks_direct() routine as
   the get_block callback to blockdev_direct_IO() -- so no use of
   _own_locking().  This would simply return blocks from uninit extents;
   extent conversion (including possible splitting) would then be done in
   ext4_direct_IO().

7. Ted's last comment is about the tradeoffs between getting the journal
   transaction correct vs aggressive zeroout of data blocks -- seeing if
   it's possible to bypass the journal in the case of preallocated DIO
   writes.

Looking through these, it seems to me that there are two major problems:

   a. How to correctly do extent conversion in the face of locking issues and
      races with other requests (e.g. AIO)

   b. How to efficiently do this extent conversion in the face of correct
      journal semantics.

Have I missed anything?

Jan's idea of a new get_block callback for DIO seems like the simplest
solution to (a) above.  No locking changes would seem to be needed, I think.
Does this seem reasonable?

Problem (b) is one that I would defer to others with more experience with
journals than I have.

Thanks,
Curt
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html