lkml.org 
[lkml]   [2004]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: To kunmap_atomic or not to kunmap_atomic ?
Hugh Dickins wrote:
>
> On Thu, 1 Apr 2004, Zoltan Menyhart wrote:
> > I can see a couple of functions, like
> >
> > static inline struct mm_struct * ptep_to_mm(pte_t * ptep)
> > {
> > struct page * page = kmap_atomic_to_page(ptep);
> > return (struct mm_struct *) page->mapping;
> > }
> >
> > in "rmap.?" without invoking "kunmap_atomic()".
> > Is it intentional?
> > What if for an architecture "kunmap_atomic()" is not a no-op ?
>
> Amusing misunderstanding. Take a look at kmap_atomic_to_page
> in arch/i386/mm/highmem.c: it doesn't _do_ a kmap_atomic, it
> translates the virtual address already supplied by kmap_atomic
> to the address of the struct page of the physical page backing
> that virtual address. So, in the case of try_to_unmap_one, it
> operates on the virtual address supplied by rmap_ptep_map
> (which does do a kmap_atomic), and at the end there's an
> rmap_ptep_unmap (which does the rmap_ptep_unmap).
>
> Hugh

As you have *map* - *unmap* macros / functions, they give a _hint_
that the original intention of the author was to allow some
architectures - which do need some resources to map things -
manage these resources. See:

static inline void *kmap(struct page *page)
#define kunmap(page)

#define kmap_atomic(page, idx)
#define kunmap_atomic(addr, idx)
#define kmap_atomic_to_page(ptr)

I think we cannot guarantee that we will never ever need to
unmap things. As it is required to use kmap - kunmap in pair,
it is quite logic to use kmap_atomic* in pair with kunmap_atomic.

I think it is a bad programming style to abuse the fact that
some macros are no-ops for the most popular architectures.

I think we should have some global counters in DEBUG mode which
are incremented on each call to *map* and decremented on each
*unpap* call, and we can detect, ooops, it leaks...

Regards,

Zoltán Menyhárt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.048 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site