linux-kernel - Re: Adding an ugliness in __read_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]

Date:	Sun, 22 May 2011 16:46:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: Adding an ugliness in __read_cache_page()?

On Sun, May 22, 2011 at 3:25 PM, Hugh Dickins <hughd@...gle.com> wrote:
>
> But drivers/gpu/drm i915 and ttm are using read_cache_page_gfp() or
> read_mapping_page() on tmpfs: on objects created by shmem_file_setup().
>
> Nothing else uses read_cache_page_gfp().  I cannot find anything else
> using read_mapping_page() on tmpfs, but wonder if something might be
> out there.  Stacked filesystems appear not to go that way nowadays.
>
> Would it be better to make i915 and ttm call shmem_read_cache_page()
> directly?  Perhaps removing the then unused read_cache_page_gfp(), or
> perhaps not: may still be needed for i915 and ttm on tiny !SHMEM ramfs.

I would certainly prefer the "make i915 and ttm call
shmem_read_cache_page directly" approach over putting some nasty hack
in __read_cache_page.

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