All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: paul.burton@imgtec.com, gregkh@linuxfoundation.org,
	leonid.yegoshin@imgtec.com, ralf@linux-mips.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "MIPS: Fix get_frame_info() handling of microMIPS function size" has been added to the 4.4-stable tree
Date: Wed, 08 Mar 2017 07:59:36 +0100	[thread overview]
Message-ID: <1488956376237146@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    MIPS: Fix get_frame_info() handling of microMIPS function size

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mips-fix-get_frame_info-handling-of-micromips-function-size.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From b6c7a324df37bf05ef7a2c1580683cf10d082d97 Mon Sep 17 00:00:00 2001
From: Paul Burton <paul.burton@imgtec.com>
Date: Mon, 7 Nov 2016 15:07:04 +0000
Subject: MIPS: Fix get_frame_info() handling of microMIPS function size

From: Paul Burton <paul.burton@imgtec.com>

commit b6c7a324df37bf05ef7a2c1580683cf10d082d97 upstream.

get_frame_info() is meant to iterate over up to the first 128
instructions within a function, but for microMIPS kernels it will not
reach that many instructions unless the function is 512 bytes long since
we calculate the maximum number of instructions to check by dividing the
function length by the 4 byte size of a union mips_instruction. In
microMIPS kernels this won't do since instructions are variable length.

Fix this by instead checking whether the pointer to the current
instruction has reached the end of the function, and use max_insns as a
simple constant to check the number of iterations against.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14530/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/kernel/process.c |   12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -289,9 +289,9 @@ static inline int is_sp_move_ins(union m
 static int get_frame_info(struct mips_frame_info *info)
 {
 	bool is_mmips = IS_ENABLED(CONFIG_CPU_MICROMIPS);
-	union mips_instruction insn, *ip;
-	unsigned max_insns = info->func_size / sizeof(union mips_instruction);
-	unsigned i;
+	union mips_instruction insn, *ip, *ip_end;
+	const unsigned int max_insns = 128;
+	unsigned int i;
 
 	info->pc_offset = -1;
 	info->frame_size = 0;
@@ -300,11 +300,9 @@ static int get_frame_info(struct mips_fr
 	if (!ip)
 		goto err;
 
-	if (max_insns == 0)
-		max_insns = 128U;	/* unknown function size */
-	max_insns = min(128U, max_insns);
+	ip_end = (void *)ip + info->func_size;
 
-	for (i = 0; i < max_insns; i++, ip++) {
+	for (i = 0; i < max_insns && ip < ip_end; i++, ip++) {
 		if (is_mmips && mm_insn_16bit(ip->halfword[0])) {
 			insn.halfword[0] = 0;
 			insn.halfword[1] = ip->halfword[0];


Patches currently in stable-queue which might be from paul.burton@imgtec.com are

queue-4.4/mips-calculate-micromips-ra-properly-when-unwinding-the-stack.patch
queue-4.4/mips-fix-get_frame_info-handling-of-micromips-function-size.patch
queue-4.4/mips-handle-micromips-jumps-in-the-same-way-as-mips32-mips64-jumps.patch
queue-4.4/mips-fix-is_jump_ins-handling-of-16b-micromips-instructions.patch
queue-4.4/mips-clear-isa-bit-correctly-in-get_frame_info.patch
queue-4.4/mips-prevent-unaligned-accesses-during-stack-unwinding.patch

                 reply	other threads:[~2017-03-08  7:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1488956376237146@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=leonid.yegoshin@imgtec.com \
    --cc=paul.burton@imgtec.com \
    --cc=ralf@linux-mips.org \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.