From: Andrew Morton <akpm@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, bernds_cb1@t-online.de, sam@ravnborg.org,
dhowells@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] FDPIC: Add coredump capability for the ELF-FDPIC binfmt [try #3]
Date: Thu, 6 Jul 2006 10:52:23 -0700 [thread overview]
Message-ID: <20060706105223.97b9a531.akpm@osdl.org> (raw)
In-Reply-To: <20060706124727.7098.44363.stgit@warthog.cambridge.redhat.com>
On Thu, 06 Jul 2006 13:47:27 +0100
David Howells <dhowells@redhat.com> wrote:
> From: David Howells <dhowells@redhat.com>
>
> Add coredump capability for the ELF-FDPIC binfmt.
>
> ..
>
> +static int dump_seek(struct file *file, off_t off)
> +{
> + if (file->f_op->llseek) {
> + if (file->f_op->llseek(file, off, 0) != off)
> + return 0;
> + } else {
> + file->f_pos = off;
> + }
> + return 1;
> +}
llseek takes a loff_t and file->f_pos is loff_t. I guess it's a bit moot
on such a CPU. Was it deliberate?
(how come the kernel doesn't have a SEEK_SET #define?)
> +/*
> + * Decide whether a segment is worth dumping; default is yes to be
> + * sure (missing info is worse than too much; etc).
> + * Personally I'd include everything, and use the coredump limit...
> + *
> + * I think we should skip something. But I am not sure how. H.J.
> + */
> +static inline int maydump(struct vm_area_struct *vma)
> +{
> + /* Do not dump I/O mapped devices or special mappings */
> + if (vma->vm_flags & (VM_IO | VM_RESERVED)) {
> + kdcore("%08lx: %08lx: no (IO)", vma->vm_start, vma->vm_flags);
> + return 0;
> + }
> +
> + /* If we may not read the contents, don't allow us to dump
> + * them either. "dump_write()" can't handle it anyway.
> + */
> + if (!(vma->vm_flags & VM_READ)) {
> + kdcore("%08lx: %08lx: no (!read)", vma->vm_start, vma->vm_flags);
> + return 0;
> + }
> +
> + /* Dump shared memory only if mapped from an anonymous file. */
> + if (vma->vm_flags & VM_SHARED) {
> + if (vma->vm_file->f_dentry->d_inode->i_nlink == 0) {
> + kdcore("%08lx: %08lx: no (share)", vma->vm_start, vma->vm_flags);
> + return 1;
> + }
> +
> + kdcore("%08lx: %08lx: no (share)", vma->vm_start, vma->vm_flags);
> + return 0;
> + }
> +
> +#ifdef CONFIG_MMU
> + /* If it hasn't been written to, don't write it out */
> + if (!vma->anon_vma) {
> + kdcore("%08lx: %08lx: no (!anon)", vma->vm_start, vma->vm_flags);
> + return 0;
> + }
> +#endif
> +
> + kdcore("%08lx: %08lx: yes", vma->vm_start, vma->vm_flags);
> + return 1;
> +}
Three callsites - seems too large to inline.
> +#define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
The GFS2 tree has
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -32,6 +32,7 @@ #define STACK_MAGIC 0xdeadbeef
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
#define KERN_EMERG "<0>" /* system is unusable */
Which seems reasonable to me. I'll steal it from them.
> +/* #define DEBUG */
> +
> +#define DUMP_WRITE(addr, nr) \
> + do { if (!dump_write(file, (addr), (nr))) return 0; } while(0)
> +#define DUMP_SEEK(off) \
> + do { if (!dump_seek(file, (off))) return 0; } while(0)
>
> ...
>
> +#undef DUMP_WRITE
> +#undef DUMP_SEEK
> +
> +#define DUMP_WRITE(addr, nr) \
> + if ((size += (nr)) > limit || !dump_write(file, (addr), (nr))) \
> + goto end_coredump;
> +#define DUMP_SEEK(off) \
> + if (!dump_seek(file, (off))) \
> + goto end_coredump;
Embedding returns and gotos in macros is evil. For new code it's worth
doing it vaguely tastefully.
ret = dump_write(...);
if (ret < 0)
goto actually_return_an_error_code;
> + for (vml = current->mm->context.vmlist; vml; vml = vml->next)
> + segs++;
Does this need locking?
next prev parent reply other threads:[~2006-07-06 17:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-06 12:47 [PATCH 0/6] Fix FRV, ELF-FDPIC and NOMMU stuff " David Howells
2006-07-06 12:47 ` [PATCH 1/6] FDPIC: Fix FDPIC compile errors " David Howells
2006-07-06 13:40 ` David Woodhouse
2006-07-07 9:41 ` David Howells
2006-07-06 12:47 ` [PATCH 2/6] FRV: Fix FRV arch " David Howells
2006-07-06 17:31 ` Andrew Morton
2006-07-06 17:36 ` Andrew Morton
2006-07-06 18:25 ` David Howells
2006-07-06 18:39 ` Andrew Morton
2006-07-06 19:02 ` David Howells
2006-07-06 18:29 ` David Howells
2006-07-06 12:47 ` [PATCH 3/6] NOMMU: Fix execution off of ramfs with mmap() " David Howells
2006-07-06 12:47 ` [PATCH 4/6] FDPIC: Adjust the ELF-FDPIC driver to conform more to the CodingStyle " David Howells
2006-07-06 12:47 ` [PATCH 5/6] FDPIC: Add coredump capability for the ELF-FDPIC binfmt " David Howells
2006-07-06 17:52 ` Andrew Morton [this message]
2006-07-06 18:38 ` David Howells
2006-07-06 23:27 ` Andrew Morton
2006-07-07 9:46 ` David Howells
2006-07-07 10:54 ` David Howells
2006-07-07 11:00 ` David Howells
2006-07-07 11:12 ` Andrew Morton
2006-07-07 9:54 ` David Howells
2006-07-07 10:20 ` Andrew Morton
2006-07-07 10:34 ` David Howells
2006-07-06 12:47 ` [PATCH 6/6] FRV: Introduce asm-offsets for FRV arch " David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060706105223.97b9a531.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=bernds_cb1@t-online.de \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®