linux-kernel - Re: [RFC][PATCH] kmap_atomic

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:	Thu, 08 Oct 2009 18:27:26 -0400
From:	jim owens <jowens@...com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Avi Kivity <avi@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC][PATCH] kmap_atomic_push

So if I understand this correctly, the sequence:

in = kmap_atomic(inpage, KM_USER1);

out = kmap_atomic(outpage, KM_USER0);

kunmap_atomic(in, KM_USER1);

in = kmap_atomic(next_inpage, KM_USER1);

is now illegal with this patch, which breaks code
I am testing now for btrfs.

My code does this because the in/out are zlib inflate
and the in/out run at different rates.

OK, the code is not submitted yet and I can redesign the
code using a temp buffer for out and copy every byte or
use kmap(), either of them at some performance cost.

I'm just pointing out that there are cases where this
stack design puts an ugly restriction on use.

So if I understand this right, I don't love the patch (:

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