linux-kernel - Re: [PATCH 00/12] kmap

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jun 2012 15:18:08 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Cong Wang <amwang@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 00/12] kmap_atomic cleanup for 3.6

On Monday 25 June 2012, Cong Wang wrote:
> On Sat, 2012-06-23 at 21:11 +0000, Arnd Bergmann wrote:
> > On Saturday 23 June 2012, Cong Wang wrote:
> > > After few releases, it seems there are no more callers
> > > using the deprecated form of kmap_atomic(), the one
> > > with two parameters. So we can remove it now and remove
> > > the KM_* definition except KM_TYPE_NR together.
> > > 
> > > All the patches are available at:
> > > 
> > >         git://github.com/congwang/linux.git #kmap_atomic
> > > 
> > 
> > What is the significance of having an architecture-specific
> > definition for KM_TYPE_NR now? Should that be replaced
> > with a fixed value in include/linux/highmem.h so we can
> > remove the asm/kmap_types.h files entirely?
> > 
> 
> Different arch has different values for KM_TYPE_NR, I am not sure if
> unifying them to a fixed value could fit all? 

Well, that's something you could find out in the review.

> For safety, I kept their original values.

My fear is that it will make it harder to clean that code up for
real, when there is no longer an indication about where the number
comes from.

The only architecture that actually seems to have a restriction
here is tile, which defines it to 8.

I would suggest putting that value into include/linux/highmem.h,
it seems more than sufficient.  I would structure the series to
have your patches 1 and 9 through 12 first, then remove
all explicit #include <asm/kmap_types.h> statements (you have
proven that they are not required already) and finally add the
define in linux/highmem.h and remove the arch specific headers.

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