Hi,
David Miller wrote: [Wed Feb 19 2014, 07:44:01PM EST]
> From: Bob Picco <bpicco@xxxxxxxxxx>
> Date: Tue, 18 Feb 2014 14:11:18 -0500
>
> > +#ifdef CONFIG_STRICT_DEVMEM
> > +/* devmem_is_allowed for sparc.
> > + */
> > +int devmem_is_allowed(unsigned long pagenr)
> > +{
> > + int rc = page_is_ram(pagenr);
> > +
> > + return rc;
> > +}
> > +#endif
>
> We already go through all of the effort to build
> sparc64_valid_addr_bitmap, please use it via kern_addr_valid().
Sure we certainly can accomplish it this way and probably should.
>
> Using resources is over-engineering. We never provided that stuff
> in /proc/iomem on sparc so no need to add it unnecessarily.
Well over-engineering might be a strong word for a path that isn't hot.
/proc/iomem would be nice with it similar to x86_64.
It seems required with kexec-tools/kexec which is functional for T4/T5 but
not ready. Though I suppose you could have only "Crash kernel".
Also I can't think of a way to make "crash" operational without
CONFIG_DEVKMEM. Though I've had little time to ponder.
For example on T5-8 the head of /proc/iomem is:
30400000-3fdde47fff : System RAM
3fdde4e000-3fdde4ffff : System RAM
80000000000-83fffffffff : System RAM
100000000000-103fffffffff : System RAM
180000000000-183fffffffff : System RAM
200000000000-203fffffffff : System RAM
280000000000-283fffffffff : System RAM
300000000000-303fffffffff : System RAM
380000000000-383fffccbfff : System RAM
380000004000-38000051661f : Kernel code
380000516620-380000864e3f : Kernel data
380000900000-380001180838 : Kernel bss
383f5f400000-383f7f3fffff : Crash kernel
383fffcec000-383fffcfbfff : System RAM
383fffd0e000-383fffd0ffff : System RAM
800000000000-80007effffff : /pci@300
...
How about a combination of your suggestion and /proc/iomem?
>
> Furthermore, the /dev/kmem device probably needs similar restrictions,
> it just blindly copies things as long as the address is lower than
> high memory.
Ah, the holes. I'll attempt and find time to engage.
thanx,
bob
>
> All of this stuff can potentially trigger bus errors, and really the
> right thing to do is:
>
> 1) Add the necessary address validations as being discussed here
>
> 2) Put the accessed behind something like the PCI config space poking
> framework, it is able to recover from BUS errors cleanly. Take
> a look at the code mentioning 'pci_poke_in_progress'.
>
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
