linux-kernel - Re: [PATCH] support O

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]

Date:	Tue, 09 Jan 2007 11:17:24 -0600
From:	Michael Reed <mdr@....com>
To:	Peter Staubach <staubach@...hat.com>
CC:	Hua Zhong <hzhong@...il.com>, linux-kernel@...r.kernel.org,
	hugh@...itas.com, hch@...radead.com, kenneth.w.chen@...el.com,
	akpm@...l.org, torvalds@...l.org
Subject: Re: [PATCH] support O_DIRECT in tmpfs/ramfs



Peter Staubach wrote:
> Hua Zhong wrote:
>> Hi,
>>
>> A while ago there was a discussion about supporting direct-io on tmpfs.
>>
>> Here is a simple patch that does it.
>>
>> 1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
>>    if this flag is set (suggestions on a better name?)
>>
>> 2. Specify FS_RAM_BASED for tmpfs and ramfs.
>>
>> 3. When EINVAL is returned only a fput is done. I changed it to go
>>    through cleanup_all. But there is still a cleanup problem:
>>
>>   If a new file is created and then EINVAL is returned due to O_DIRECT,
>>   the file is still left on the disk. I am not exactly sure how to fix
>>   it other than adding another fs flag so we could check O_DIRECT
>>   support at a much earlier stage. Comments on how to fix it?
> 
> This would seem to create two different sets of O_DIRECT semantics,
> wouldn't it?  I think that it would be possible to develop an application
> using one of these FS_RAM_BASED file systems as the testbed, but then be
> surprised when the application failed to work on other file systems such
> as ext3.

As I'm ignorant with regard to what is needed for "compliant"
support of O_DIRECT on tmpfs, what are the issues with actually implementing
the proper semantics, including the alignment and any transfer length
restrictions?

My $.02 is that the implementation should be fully compliant with the
current semantics or it shouldn't be implemented.  And I think it should
be implemented.

Mike

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