Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>,
	Greg KH <gregkh@suse.de>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Dan Aloni <da-x@monatomic.org>
Subject: Re: [PATCH] kdump: Fix exported size of vmcoreinfo note
Date: Tue, 14 Jan 2014 15:35:54 -0800	[thread overview]
Message-ID: <20140114153554.88b4a8c193b88df9492f6973@linux-foundation.org> (raw)
In-Reply-To: <20140114193311.GL3096@redhat.com>

On Tue, 14 Jan 2014 14:33:11 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:

> Right now we seem to be exporting the max data size contained inside
> vmcoreinfo note. But this does not include the size of meta data around
> vmcore info data. Like name of the note and starting and ending elf_note.
> 
> I think user space expects total size and that size is put in PT_NOTE
> elf header. Things seem to be fine so far because we are not using
> vmcoreinfo note to the maximum capacity. But as it starts filling up,
> to capacity, at some point of time, problem will be visible.

urgh.  This is what we get for adding undocumented interfaces.

Looking through the fd59d231f81cb0287 changelog and the various email
threads it points to I can find no mention of what vmcoreinfo is
*supposed* to contain.  It was just kinda silently tossed in there.

So as a remedial step, could we please get this and any associated
interfaces written down in a way which people can very belatedly
review?

Phrases like "I think user space expects" and "Things seem to be fine
so far" don't inspire a ton of confidence.  What are the chances of
userspace breakage here?  Would it be safer/saner to leave vmcoreinfo
alone and add a new vmcoreinfo2 with the altered behaviour?

> --- linux-2.6.orig/kernel/ksysfs.c	2014-01-14 14:09:42.107767503 -0500
> +++ linux-2.6/kernel/ksysfs.c	2014-01-14 14:15:24.385510314 -0500
> @@ -126,7 +126,7 @@ static ssize_t vmcoreinfo_show(struct ko
>  {
>  	return sprintf(buf, "%lx %x\n",
>  		       paddr_vmcoreinfo_note(),
> -		       (unsigned int)vmcoreinfo_max_size);
> +		       (unsigned int)sizeof(vmcoreinfo_note));
>  }
>  KERNEL_ATTR_RO(vmcoreinfo);
>  

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2014-01-14 23:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14 19:33 [PATCH] kdump: Fix exported size of vmcoreinfo note Vivek Goyal
2014-01-14 19:35 ` Vivek Goyal
2014-01-14 23:35 ` Andrew Morton [this message]
2014-01-15 15:12   ` Vivek Goyal

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=20140114153554.88b4a8c193b88df9492f6973@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=da-x@monatomic.org \
    --cc=gregkh@suse.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oomichi@mxs.nes.nec.co.jp \
    --cc=vgoyal@redhat.com \
    /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