mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anurag Aggarwal <a.anurag@samsung.com>
To: Dave Martin <Dave.Martin@arm.com>,
	Anurag Aggarwal <anurag19aggarwal@gmail.com>
Cc: Naveen Kumar <naveen.sel@samsung.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Narendra Meher <narendra.m1@samsung.com>,
	"nico@linaro.org" <nico@linaro.org>,
	Anurag Aggarwal <a.anurag@samsung.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"cpgs ." <cpgs@samsung.com>,
	"naveenkrishna.ch@gmail.com" <naveenkrishna.ch@gmail.com>,
	Rajat Suri <rajat.suri@samsung.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Mohammad Irfan Ansari <mohammad.a2@samsung.com>
Subject: Re: Re: [PATCH] ARM: unwinder: Handle Stackoverflow in unwind_exec_insn
Date: Mon, 25 Nov 2013 09:10:40 +0000 (GMT)	[thread overview]
Message-ID: <31564068.33481385370637554.JavaMail.weblogic@epv6ml06> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 2811 bytes --]

Hi Dave,

I think that we don't need to avoid stack overflow completely but we need to avoid data being derefrenced that is not part of stack.

I agree with you that there is no rule in ABI to guarantee that stack overflow will only occur when backtracking last set of register.

>From my understanding of code the only chances of getting a data abort is while executing these four instructions:
1) 1000iiii iiiiiiii : Pop up to 12 integer registers under masks {r15-r12}, {r11-r4}
2) 10100nnn : Pop r4-r[4+nnn]
3) 10101nnn : Pop r4-r[4+nnn], r14
4) 10110001 0000iiii : Pop integer registers under mask {r3, r2, r1, r0}

I think it would be better to execute these instruction in their own seperate functions, which would be called from unwind_exec_insn, and in those function depending on the depth of stack remaining we can decide whether it is possible to execute the instruction or not.

The above method will add some extra code but will avoid additional checks that are not required every where.

and solve our purpose also as we need to avoid data abort due to stack overflow not stack overflow completely.

Regards
Anurag Aggarwal

------- Original Message -------
Sender : Dave Martin<Dave.Martin@arm.com>
Date : Nov 23, 2013 01:07 (GMT+05:30)
Title : Re: [PATCH] ARM: unwinder: Handle Stackoverflow in unwind_exec_insn

On Sat, Nov 09, 2013 at 12:28:57PM +0530, Anurag Aggarwal wrote:
> Thanks for your input Dave,
> 
> I think there is another way to avoid the stack overflow and reduce
> the number of checks also,
> 
> Stack overflow will cause a problem only when we are backtracking the
> last set of registers.
> i.e when the difference between current SP and top of stack is less
> than or equal to number of registers

Apologies, it looks like I failed to respond to this earlier...


Although that will usually be correct, there is no rule in the ABI to
guarantee it.

> we can create two unwind_exec_insn, one without checks and one with checks.
> 
> then we call the correct function from unwind_frame depending on the
> difference of SP and top of stack.
> 
> This will reduce the amount of checks every time we read a set of
> registers from stack

That sounds like it might duplicate a lot of code, to optimise based on
assumptions that may not always be true, for what really should not be a
hot path in the kernel.

If you can find a tidy way of doing it, it would be certainly worth
reviewing, but I still think it would be simpler just to do a simple
bounds check for every word read from the stack -- it should be
impossible for that to go wrong, even if some of the bounds checks
are not stictly required.

Cheers
---Daveÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

                 reply	other threads:[~2013-11-25  9:10 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=31564068.33481385370637554.JavaMail.weblogic@epv6ml06 \
    --to=a.anurag@samsung.com \
    --cc=Dave.Martin@arm.com \
    --cc=anurag19aggarwal@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=cpgs@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mohammad.a2@samsung.com \
    --cc=narendra.m1@samsung.com \
    --cc=naveen.sel@samsung.com \
    --cc=naveenkrishna.ch@gmail.com \
    --cc=nico@linaro.org \
    --cc=rajat.suri@samsung.com \
    --cc=will.deacon@arm.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

all inboxes | Powered by JetHome®