linux-kernel - Re: [git patches] xfs and block fixes for virtually indexed arches

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: <20091218192401D.fujita.tomonori@lab.ntt.co.jp>
Date:	Fri, 18 Dec 2009 19:24:12 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	James.Bottomley@...e.de
Cc:	fujita.tomonori@....ntt.co.jp, jens.axboe@...cle.com,
	torvalds@...ux-foundation.org, tytso@....edu, kyle@...artin.ca,
	linux-parisc@...r.kernel.org, linux-kernel@...r.kernel.org,
	hch@...radead.org, linux-arch@...r.kernel.org
Subject: Re: [git patches] xfs and block fixes for virtually indexed arches

On Fri, 18 Dec 2009 11:01:29 +0100
James Bottomley <James.Bottomley@...e.de> wrote:

> > Yeah, but now only XFS passes vmap'ed pages to the block layer. Isn't
> > it better to wait until we have real users of the API?
> 
> XFS is a real user ... the XFS filesystem is our most trusted code base
> that can break the 8TB limit, which hard disks are already at.  Ext4 may
> be ready, but it's not universally present in enterprise distros like
> XFS.

XFS already has the own code to handle that, which works fine (with
your patchset except for 5/6 for the block layer). Not much motivation
for XFS to move to the generic API?


> > > That would ensure the architecturally
> > > correct flushing of the aliases, and would satisfy the expectations of
> > > blk_rq_map_kern().  The down side is that vmap/vmalloc set up and clear
> > > page tables, which isn't necessary and might impact performance (xfs
> > > people?)
> > 
> > btw, I'm not sure that the existing blk_rq_map_* API isn't fit well to
> > file systems since blk_rq_map_user and blk_rq_map_kern takes a request
> > structure.
> 
> OK, so that was illustrative.  The meat of the change is at the bio
> layer anyway (fss tend to speak bios).

Yeah, I think so, it's up to Jens to add new APIs for vmap there.
--
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/