> Who can tell? rmk's mail sugggests it should work on some valid RAM.
Not really. If I understand Russell here, that RAM has been "put aside"
for use by fancy stuff and is de-facto out of control of the normal page
allocator and refcounting. In this case, I see no reason why it couldn't
be considered as MMIO and ioremap'able :)
> ioremap is making a similar check to the one remap_pfn_range used
> to make; but I see no good reason for it at all. ioremap should be
> allowed to map whatever the caller asked, just as memset is allowed
> to set whatever the caller asked.
This is dodgy actually. memset can't be guaranteed to work on IOs or
other non-cacheable memory (including real RAM that has been mapped
non-cacheable, typically RAM that has been "set aside" for other uses as
described above, wether it's for AGP, or for some weird processor DMA
bounce buffers or whatever ..., that is RAM that is out of the normal
kernel control).
> It's up to the caller to get it
> right, not for the function to demand the added reassurance of some
> mysterious page flag being set.
>
> (But in what I said earlier about VM_RESERVE making sure wrong pages
> not freed, I was confused and confusing ioremap with remap_pfn_range.)
>
> > I thought the fact that it *won't* bail out when encountering
> > kernel text or remap_pfn_range'ed pages was only due to PG_reserved
> > being the proverbial jack of all trades, master of none.
> >
> > I could be wrong here though.
> >
> > But in either case: I agree that it is probably not a great loss
> > to remove the check, although considering it will be needed for
> > swsusp anyway...
>
> swsusp (and I think crashdump has a similar need) is a very different
> case: it's approaching memory from the zone/mem_map end, with no(?) idea
> of how the different pages are used: needs to save all the info while
> avoiding those areas which would give trouble. I can well imagine it
> needs either a page flag or a table lookup to decide that.
>
> But ioremap and remap_pfn_range are coming from drivers which (we hope)
> know what they're mapping these particular areas for. If it's provable
> that the meaning which swsusp needs is equally usable for a little sanity
> check in ioremap, okay, but I'm sceptical.
>
> Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |