linux-kernel - Re: EXPORT_SYMBOL(fat_get

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: <20100813185005.GA21112@infradead.org>
Date:	Fri, 13 Aug 2010 14:50:05 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	David Cross <david.cross@...ress.com>
Cc:	Greg KH <gregkh@...e.de>, hirofumi@...l.parknet.co.jp,
	linux-kernel@...r.kernel.org
Subject: Re: EXPORT_SYMBOL(fat_get_block)

On Fri, Aug 13, 2010 at 11:43:12AM -0700, David Cross wrote:
> OK, I am trying to answer all questions on this topic that I am getting,
> but honestly I have not gotten a lot so far. 

Seriously, I think there is absolutely no point in even arguing this.
A driver has absolutely no business looking into any filesystem layout.

> 1) receive all data, buffer it, then write the file. This is typically a
> slow process USB->Processor->SDRAM->Processor/DMA engine->Media
> 2) pre-allocate the file as soon as it knows that it is coming and how
> big it is, and then send the block addresses to an external DMA engine
> and let it transfer the data from the MTP host directly
> 
> The West Bridge driver goes for option two for performance reasons. In
> doing this, it needs to get information from the file system on where to
> store the file.

And what if someone else changes the layout undernath you?  Or uses
a different filesystem?

Basically you will have to introduce operations to the VFS to lock down
a file against layout changes and do DMA transfers.  It's fine if you
only implement it for fat in the beginning, and just return an error
for others, although in general the implementation would be easily
extendable to other filesystems using generic code and the get_blocks
callbacks.
--
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/