linux-kernel - Re: [PATCH] Proposed update to the kernel kmap/kunmap API

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] [day] [month] [year] [list]

Message-Id: <1154896384.3683.238.camel@mulgrave.il.steeleye.com>
Date:	Sun, 06 Aug 2006 15:33:04 -0500
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Proposed update to the kernel kmap/kunmap API

On Sun, 2006-08-06 at 12:48 -0700, Andrew Morton wrote:
> kmap() is a nasty thing.  It has theoretical deadlock problems (which used
> to be real ones back in the 2.4 days) and the present implementation uses a
> kernel-wide lock.
> 
> We've been gradually and sporadically working to make kmap() go away, so
> please let's not do anything which encourages its use.
> 
> kmap_atomic() is much preferred.  Can this initiative be recast around
> kmap_atomic()?

Well the API change intercepts both kmap/kunmap and
kmap_atomic/kunmap_atomic; it's designed to be agnostic to the _atomic
bit (I just wrote kmap/kunmap in the Subject line because I was saving
letters).  Since it's intended as a flushing API, it has no context
issues, so the parisc implementation is the similar for both (the only
difference being the return value).

However, while kmap exists, it also has to be intercepted for this
approach to work...

James

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