From: Jay Lan <jlan@sgi.com>
To: Simon Horman <horms@verge.net.au>
Cc: kexec@lists.infradead.org, Bernhard Walle <bwalle@suse.de>,
"Luck, Tony" <tony.luck@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: [patch] ia64: Order of operations bug in PT_LOAD segment reader
Date: Tue, 21 Oct 2008 16:52:27 +0000 [thread overview]
Message-ID: <48FE08CB.5080308@sgi.com> (raw)
In-Reply-To: <20081008064940.GA11893@verge.net.au>
Simon Horman wrote:
Hi Simon,
Just got back from vacation. Sorry for late response.
> This bug was discovered by Jay Lan and he also proposed this fix, however
> thee is some discussion about what if any related changes should be made at
> the same time.
>
> The bug comes about because the break statment was never executed because
> the if clause would bever be true because the if clause will never be true
> because & has higher precedence than !=.
>
> My position on this is that with the if logic fixed, as per this patch, the
> break statment and the rest of the while() loop makes sense and should work
> as intended.
>
> As I understand it, Jay's position is that the code should be simplified,
> after all it never worked as intended.
>
> There is a related kernel bug that lead Jay to discover this problem.
> The kernel bug has been resolved by Tony Luck and was
> included in Linus's tree between 2.6.27-rc8 and 2.6.27-rc9 as
> "[IA64] Put the space for cpu0 per-cpu area into .data section".
>
> Now that the kernel bug is out of the way, I am providing this patch to
> continue discussion on what to do on the kexec-tools side of things. I do
> not intend to apply this patch until there is some conclusion in the
> discussion between Jay and myself.
I think this patch is not right for two reasons:
1) The if-statement below has never proved the correctness of
its intent because the 'break' statement never got executed
due to a logic error.
if (loaded_segments[loaded_segments_num].end ! (phdr->p_paddr & ~(ELF_PAGE_SIZE-1)))
break;
2) With your patch in my testing, the kdump kernel boot hung
even earlier in a PAL_CALL that was not returned to the kernel.
I understand that my test case was based on a kernel without
Tony's latest fix, but that was the only situation we can
see the if-statement becomes true. I do not know any other
way to make a memory gap happen. However, when it happens,
your patch only makes kdump kenrel boot hang earlier.
I still root for my patch because the kdump kernel would boot
correctly even if a memory gap indeed happened. ;) However,
if you do not feel comfortable with my patch, i think the best
alternative is to take out the if-statement above completely.
Regards,
jay
>
> Cc: Jay Lan <jlan@sgi.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> Index: kexec-tools/kexec/arch/ia64/crashdump-ia64.c
> =================================> --- kexec-tools.orig/kexec/arch/ia64/crashdump-ia64.c 2008-10-08 17:31:42.000000000 +1100
> +++ kexec-tools/kexec/arch/ia64/crashdump-ia64.c 2008-10-08 17:32:08.000000000 +1100
> @@ -91,7 +91,7 @@ static void add_loaded_segments_info(str
> if (phdr->p_type != PT_LOAD)
> break;
> if (loaded_segments[loaded_segments_num].end !> - phdr->p_paddr & ~(ELF_PAGE_SIZE-1))
> + (phdr->p_paddr & ~(ELF_PAGE_SIZE-1)))
> break;
> loaded_segments[loaded_segments_num].end +> (phdr->p_memsz + ELF_PAGE_SIZE - 1) &
>
next prev parent reply other threads:[~2008-10-21 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 6:49 [patch] ia64: Order of operations bug in PT_LOAD segment reader Simon Horman
2008-10-08 7:56 ` Andreas Schwab
2008-10-08 22:09 ` Simon Horman
2008-10-21 16:52 ` Jay Lan [this message]
2008-10-22 23:25 ` Simon Horman
2008-10-22 23:47 ` Jay Lan
2008-10-23 0:01 ` Simon Horman
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=48FE08CB.5080308@sgi.com \
--to=jlan@sgi.com \
--cc=bwalle@suse.de \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=tony.luck@intel.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