linux-kernel - Re: [RFC] atomic highmem kmap page pinning

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: <alpine.LFD.2.00.0903071721040.30483@xanadu.home>
Date:	Sat, 07 Mar 2009 17:28:06 -0500 (EST)
From:	Nicolas Pitre <nico@....org>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [RFC] atomic highmem kmap page pinning

On Fri, 6 Mar 2009, Minchan Kim wrote:

> On Fri, Mar 6, 2009 at 7:59 AM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > On Fri, Mar 06, 2009 at 07:23:44AM +0900, Minchan Kim wrote:
> >> > +#ifdef ARCH_NEEDS_KMAP_HIGH_GET
> >> > +/**
> >> > + * kmap_high_get - pin a highmem page into memory
> >> > + * @page: &struct page to pin
> >> > + *
> >> > + * Returns the page's current virtual memory address, or NULL if no mapping
> >> > + * exists.  When and only when a non null address is returned then a
> >> > + * matching call to kunmap_high() is necessary.
> >> > + *
> >> > + * This can be called from any context.
> >> > + */
> >> > +void *kmap_high_get(struct page *page)
> >> > +{
> >> > +       unsigned long vaddr, flags;
> >> > +
> >> > +       spin_lock_kmap_any(flags);
> >> > +       vaddr = (unsigned long)page_address(page);
> >> > +       if (vaddr) {
> >> > +               BUG_ON(pkmap_count[PKMAP_NR(vaddr)] < 1);
> >> > +               pkmap_count[PKMAP_NR(vaddr)]++;
> >> > +       }
> >> > +       spin_unlock_kmap_any(flags);
> >> > +       return (void*) vaddr;
> >> > +}
> >> > +#endif
> >>
> >> Let's add empty function for architecture of no ARCH_NEEDS_KMAP_HIGH_GET,
> >
> > The reasoning being?
> 
> I thought it can be used in common arm function.
> so, for VIVT, it can be work but for VIPT, it can be nulled as
> preventing compile error.

The issue is not about VIVT vs VIPT, but rather about the fact that IO 
transactions don't snoop the cache.  So this is needed even for current 
VIPT implementations.

> But, I don't know where we use kmap_high_get since I didn't see any
> patch which use it.
> If it is only used architecture specific place,  pz, forgot my comment.

Yes, that's the case.  And it is much preferable to have a compilation 
error than providing an empty stub to silently mask out misuses.


Nicolas