On Sun, Jan 13, 2019 at 11:33:56PM +1100, Balbir Singh wrote:
> On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote:
> > On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> > > Could you please define interesting frame on top a bit more? Usually
> > > the topmost return
On 1/14/19 12:09 PM, Josh Poimboeuf wrote:
On Mon, Jan 14, 2019 at 11:46:59AM -0500, Joe Lawrence wrote:
@@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
return 1; /* invalid backlink, too far up. */
}
+ /* We can only
On Mon, Jan 14, 2019 at 11:46:59AM -0500, Joe Lawrence wrote:
> @@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
> return 1; /* invalid backlink, too far up. */
> }
>
> + /* We can only trust the bottom frame's backlink,
On Mon, Jan 14, 2019 at 08:21:40AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > We should be careful when inspecting the bottom-most stack frame (the
> > first to be unwound), particularly for scheduled-out tasks. As Nicolai
> > Stange explains, "If I'm reading the code in
Joe Lawrence writes:
> On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
>> Joe Lawrence writes:
>>
>> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
>
> [ ... snip ... ]
>
>> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER
>> >>
On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
[ ... snip ... ]
> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER
> >> from _switch() helps?
> >>
> >>
On Sun, 13 Jan 2019 23:33:56 +1100
Balbir Singh wrote:
> On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote:
> > On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> > > Could you please define interesting frame on top a bit more?
> > > Usually the topmost return
On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote:
> On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> > Could you please define interesting frame on top a bit more? Usually
> > the topmost return address is in LR
>
> There is no reliable way (other than DWARF
On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> Could you please define interesting frame on top a bit more? Usually
> the topmost return address is in LR
There is no reliable way (other than DWARF unwind info) to find out where
the value of LR at function entry currently lives
On Thu, Jan 10, 2019 at 04:14:00PM -0500, Joe Lawrence wrote:
> Hi all,
>
> tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>about?
>
> I am looking at a bug in which ~10% of livepatch tests on RHEL-7 and
> RHEL-8 distro kernels, the ppc64le reliable stack unwinder
Joe Lawrence writes:
> On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
>> Hi Joe,
>>
>> Joe Lawrence writes:
>>
>> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>> >about?
>>
>> If I'm reading the code in _switch() correctly, the first frame is
On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
> Hi Joe,
>
> Joe Lawrence writes:
>
> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
> >about?
>
> If I'm reading the code in _switch() correctly, the first frame is
> completely uninitialized
Hi Joe,
Joe Lawrence writes:
> tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>about?
If I'm reading the code in _switch() correctly, the first frame is
completely uninitialized except for the pointer back to the caller's
stack frame.
For completeness: _switch()
Hi all,
tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
about?
I am looking at a bug in which ~10% of livepatch tests on RHEL-7 and
RHEL-8 distro kernels, the ppc64le reliable stack unwinder consistently
reports an unreliable stack for a given task. This condition
14 matches
Mail list logo
