On Tue, Apr 29, 2014 at 1:59 AM, Daniel Thompson
wrote:
> On 28/04/14 18:44, Colin Cross wrote:
Is that case documented somewhere in the code comments?
>>>
>>> Perhaps not near enough to the _nolock but the primary bit of comment is
>>> here (and in same file as kdb_sr).
>>> --- cut here ---
On 28/04/14 18:44, Colin Cross wrote:
>>> Is that case documented somewhere in the code comments?
>>
>> Perhaps not near enough to the _nolock but the primary bit of comment is
>> here (and in same file as kdb_sr).
>> --- cut here ---
>> * kdb_main_loop - After initial setup and assignment of the
On 28/04/14 18:44, Colin Cross wrote:
Is that case documented somewhere in the code comments?
Perhaps not near enough to the _nolock but the primary bit of comment is
here (and in same file as kdb_sr).
--- cut here ---
* kdb_main_loop - After initial setup and assignment of the
*
On Tue, Apr 29, 2014 at 1:59 AM, Daniel Thompson
daniel.thomp...@linaro.org wrote:
On 28/04/14 18:44, Colin Cross wrote:
Is that case documented somewhere in the code comments?
Perhaps not near enough to the _nolock but the primary bit of comment is
here (and in same file as kdb_sr).
--- cut
On 28/04/14 18:44, Colin Cross wrote:
>>> Is that case documented somewhere in the code comments?
>>
>> Perhaps not near enough to the _nolock but the primary bit of comment is
>> here (and in same file as kdb_sr).
>> --- cut here ---
>> * kdb_main_loop - After initial setup and assignment of the
On Mon, Apr 28, 2014 at 3:24 AM, Daniel Thompson
wrote:
> On 25/04/14 17:45, Steven Rostedt wrote:
>> On Fri, 25 Apr 2014 17:29:22 +0100
>> Daniel Thompson wrote:
>>
>>> If kdb is triggered using SysRq-g then any use of the sr command results
>>> in the SysRq key table lock being recursively
On 25/04/14 17:45, Steven Rostedt wrote:
> On Fri, 25 Apr 2014 17:29:22 +0100
> Daniel Thompson wrote:
>
>> If kdb is triggered using SysRq-g then any use of the sr command results
>> in the SysRq key table lock being recursively acquired, killing the debug
>> session. That patch resolves the
On 25/04/14 17:45, Steven Rostedt wrote:
On Fri, 25 Apr 2014 17:29:22 +0100
Daniel Thompson daniel.thomp...@linaro.org wrote:
If kdb is triggered using SysRq-g then any use of the sr command results
in the SysRq key table lock being recursively acquired, killing the debug
session. That
On Mon, Apr 28, 2014 at 3:24 AM, Daniel Thompson
daniel.thomp...@linaro.org wrote:
On 25/04/14 17:45, Steven Rostedt wrote:
On Fri, 25 Apr 2014 17:29:22 +0100
Daniel Thompson daniel.thomp...@linaro.org wrote:
If kdb is triggered using SysRq-g then any use of the sr command results
in the
On 28/04/14 18:44, Colin Cross wrote:
Is that case documented somewhere in the code comments?
Perhaps not near enough to the _nolock but the primary bit of comment is
here (and in same file as kdb_sr).
--- cut here ---
* kdb_main_loop - After initial setup and assignment of the
*
On Fri, 25 Apr 2014 17:29:22 +0100
Daniel Thompson wrote:
> If kdb is triggered using SysRq-g then any use of the sr command results
> in the SysRq key table lock being recursively acquired, killing the debug
> session. That patch resolves the problem by introducing a _nolock
> alternative for
If kdb is triggered using SysRq-g then any use of the sr command results
in the SysRq key table lock being recursively acquired, killing the debug
session. That patch resolves the problem by introducing a _nolock
alternative for __handle_sysrq.
Strictly speaking this approach risks racing on the
If kdb is triggered using SysRq-g then any use of the sr command results
in the SysRq key table lock being recursively acquired, killing the debug
session. That patch resolves the problem by introducing a _nolock
alternative for __handle_sysrq.
Strictly speaking this approach risks racing on the
On Fri, 25 Apr 2014 17:29:22 +0100
Daniel Thompson daniel.thomp...@linaro.org wrote:
If kdb is triggered using SysRq-g then any use of the sr command results
in the SysRq key table lock being recursively acquired, killing the debug
session. That patch resolves the problem by introducing a
14 matches
Mail list logo