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: <20091218183353I.fujita.tomonori@lab.ntt.co.jp>
Date:	Fri, 18 Dec 2009 18:34:52 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	James.Bottomley@...senPartnership.com
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 08:08:48 +0100
James Bottomley <James.Bottomley@...senPartnership.com> wrote:

> > Even if we have some potential users, I'm not sure that supporting
> > vmalloc in the block layer officially is a good idea. IMO, it needs
> > too many tricks for generic code.
> 
> So far, there's only xfs that I know of.
> 
> Given the way journalling works, it's not an unusual requirement to use
> a large buffer for operations.  It's a bit of a waste of kernel
> resources to have this physically contiguous, but it is a waste of
> resources (and for buffers over our kmalloc max, it would even have to
> be allocated at start of day), so I think large kernel virtual areas
> (like vmap/vmalloc) have a part to play in fs operations.

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?


> As to the API, the specific problem is that the block and lower arch
> layers are specifically programmed to think any kernel address has only
> a single alias and that it's offset mapped, which is why we get the
> failure.

Yeah, however we can make a rule that you can't pass a vmap area
(including vmap'ed pages) to the block layer. We can't make the rule
effective for the past so XFS is the only exception.


> An alternative proposal to modifying the block layer to do coherency,
> might be simply to have the fs layer do a vunmap before doing I/O and
> re-vmap when it's completed. 

I'm not sure it's worth making the whole block layer compatible to
vmap (adding complexity and possibly performance penalty).

If we really need to support this, I like helper APIs that the callers
must use before and after I/Os.


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