Messages in this thread | | | Date | Fri, 2 Apr 2004 16:10:19 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: To kunmap_atomic or not to kunmap_atomic ? |
| |
On Fri, 2 Apr 2004, Zoltan Menyhart wrote: > > > > 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). >... > > 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.
Agreed.
> I think it is a bad programming style to abuse the fact that > some macros are no-ops for the most popular architectures.
Agreed.
> 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...
If you choose CONFIG_DEBUG_HIGHMEM, kmap_atomic does check that kunmap_atomic was done last time, no need for additional counter.
Sorry, I've not made it clear.
kmap_atomic_to_page does not map anything, and doesn't need a corresponding unmap operation. It expects that you already did a kmap_atomic (and that you will later do a kunmap_atomic), and translates from the address returned by kmap_atomic to the address of the relevant struct page. You can certainly argue that it's misleadingly named, but no better name springs to my mind.
Hugh
- 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/
| |