lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 9 Sep 2008 11:22:07 +0200 From: "Vegard Nossum" <vegard.nossum@...il.com> To: "Oren Laadan" <orenl@...columbia.edu> Cc: dave@...ux.vnet.ibm.com, arnd@...db.de, jeremy@...p.org, linux-kernel@...r.kernel.org, containers@...ts.linux-foundation.org Subject: Re: [RFC v4][PATCH 4/9] Memory management (dump) On Tue, Sep 9, 2008 at 9:42 AM, Oren Laadan <orenl@...columbia.edu> wrote: > For each VMA, there is a 'struct cr_vma'; if the VMA is file-mapped, > it will be followed by the file name. The cr_vma->npages will tell > how many pages were dumped for this VMA. Then it will be followed > by the actual data: first a dump of the addresses of all dumped > pages (npages entries) followed by a dump of the contents of all > dumped pages (npages pages). Then will come the next VMA and so on. > > Signed-off-by: Oren Laadan <orenl@...columbia.edu> > --- > arch/x86/mm/checkpoint.c | 30 +++ > arch/x86/mm/restart.c | 1 + > checkpoint/Makefile | 3 +- > checkpoint/checkpoint.c | 53 ++++++ > checkpoint/ckpt_arch.h | 1 + > checkpoint/ckpt_mem.c | 448 ++++++++++++++++++++++++++++++++++++++++++++ > checkpoint/ckpt_mem.h | 35 ++++ > checkpoint/sys.c | 23 ++- > include/asm-x86/ckpt_hdr.h | 5 + > include/linux/ckpt.h | 12 ++ > include/linux/ckpt_hdr.h | 30 +++ > 11 files changed, 635 insertions(+), 6 deletions(-) > create mode 100644 checkpoint/ckpt_mem.c > create mode 100644 checkpoint/ckpt_mem.h > > diff --git a/arch/x86/mm/checkpoint.c b/arch/x86/mm/checkpoint.c > index 71d21e6..50cfd29 100644 > --- a/arch/x86/mm/checkpoint.c > +++ b/arch/x86/mm/checkpoint.c > @@ -192,3 +192,33 @@ int cr_write_cpu(struct cr_ctx *ctx, struct task_struct *t) > cr_hbuf_put(ctx, sizeof(*hh)); > return ret; > } > + > +/* dump the mm->context state */ > +int cr_write_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int parent) > +{ > + struct cr_hdr h; > + struct cr_hdr_mm_context *hh = cr_hbuf_get(ctx, sizeof(*hh)); > + int ret; > + > + h.type = CR_HDR_MM_CONTEXT; > + h.len = sizeof(*hh); > + h.parent = parent; > + > + mutex_lock(&mm->context.lock); > + > + hh->ldt_entry_size = LDT_ENTRY_SIZE; > + hh->nldt = mm->context.size; > + > + cr_debug("nldt %d\n", hh->nldt); > + > + ret = cr_write_obj(ctx, &h, hh); > + cr_hbuf_put(ctx, sizeof(*hh)); > + if (ret < 0) > + return ret; mutex_unlock(&mm->context.lock) before return, I think? > + > + ret = cr_kwrite(ctx, mm->context.ldt, hh->nldt * LDT_ENTRY_SIZE); > + > + mutex_unlock(&mm->context.lock); > + > + return ret; > +} Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists