linux-kernel - RE: open(O_DIRECT) on a tmpfs?

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: <003f01c7302f$e72164b0$0200a8c0@nuitysystems.com>
Date:	Thu, 4 Jan 2007 10:41:06 -0800
From:	"Hua Zhong" <hzhong@...il.com>
To:	"'Hugh Dickins'" <hugh@...itas.com>,
	"'Bill Davidsen'" <davidsen@....com>
Cc:	"'Linux-kernel'" <linux-kernel@...r.kernel.org>
Subject: RE: open(O_DIRECT) on a tmpfs?

> I see that as a good argument _not_ to allow O_DIRECT on 
> tmpfs, which inevitably impacts cache, even if O_DIRECT were 
> requested.
> 
> But I'd also expect any app requesting O_DIRECT in that way, 
> as a caring citizen, to fall back to going without O_DIRECT 
> when it's not supported.

According to "man 2 open" on my system:

       O_DIRECT
              Try to minimize cache effects of the I/O to and from this file.
              In  general  this will degrade performance, but it is useful in
              special situations, such as  when  applications  do  their  own
              caching.  File I/O is done directly to/from user space buffers.
              The I/O is synchronous, i.e., at the completion of the  read(2)
              or write(2) system call, data is guaranteed to have been trans-
              ferred.  Under Linux 2.4 transfer sizes, and the  alignment  of
              user  buffer and file offset must all be multiples of the logi-
              cal block size of the file system. Under Linux 2.6 alignment to
              512-byte boundaries suffices.
              A semantically similar interface for block devices is described
              in raw(8).

This says nothing about (probably disk based) persistent backing store. I don't see why tmpfs has to conflict with it.

So I'd argue that it makes more sense to support O_DIRECT on tmpfs as the memory IS the backing store.

And EINVAL isn't even a very specific error.

Hua

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