Hi!
> > > The following patch fixes Bug #4959. It creates temporary page translation
> > > tables located in the page frames that are not overwritten by swsusp while copying
> > > the image.
> > >
> > > The temporary page translation tables are generally based on the existing ones
> > > with the exception that the mappings using 4KB pages are replaced with the
> > > equivalent mappings that use 2MB pages only. The temporary page tables are
> > > only used for copying the image.
> >
> > Would not it be simpler to create them from scratch? mm/init.c has
> > some handy functions, they should be applicable. [init_memory_mapping,
> > phys_pud_init]. Perhaps even initialize only simple direct mapping,
> > and place virt_to_phys() at strategic places?
>
> Perhaps, but the outcome would be very much the same. The problem is to what
> extent we can use the existing constructs, because I'd rather like to avoid the situation
> in which any future changes to the initialization code would have to be replicated
> in the swsusp code. I'll have a look at that, but I'm not sure. Also I don't really know
> what the Andi's preferences are with this respect.
>
> Anyway do you think that creating temporary page tables at the beginning of
> swsusp_arch_resume() is a good idea? If not, where do you think should they be
> created?
For i386, I simply let bootup code create them, and create "backup
copy" that is not damaged by any page splits... Result is in
mm/init.c:
#ifdef CONFIG_SOFTWARE_SUSPEND
/*
* Swap suspend & friends need this for resume because things like the
intel-agp
* driver might have split up a kernel 4MB mapping.
*/
char __nosavedata swsusp_pg_dir[PAGE_SIZE]
__attribute__ ((aligned (PAGE_SIZE)));
static inline void save_pg_dir(void)
{
memcpy(swsusp_pg_dir, swapper_pg_dir, PAGE_SIZE);
}
#else
static inline void save_pg_dir(void)
{
}
#endif
It is probably not as simple for x86-64 case, but some bootup code
reusal still should be neccessary...
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
-
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]
| |
 |