On Tue, Jun 23, 2015 at 10:56:24AM +0200, Ingo Molnar wrote:
> So I think the theory is that crashes do happen, and that any RCU warning
> only
> matters to (usually) small race windows.
>
> So by the time a difficult crash truly happens, exactly in that race window,
> we'd
> have fixed the RC
* Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 09:26:13AM -0700, Andy Lutomirski wrote:
>
> > notify_die is misnamed and has little to do with death. It's really just
> > notifying about an exception, and we might end up oopsing, sending a
> > signal,
> > or neither.
>
> But if we oops a
On Mon, Jun 22, 2015 at 11:15 AM, Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 10:37:39AM -0700, Andy Lutomirski wrote:
>> But if we OOPS, we'll OOPS after the lockdep splat and the lockdep
>> splat will scroll off the screen, right? Am I missing something here?
>
> No, you're not.
>
>> notif
On Mon, Jun 22, 2015 at 10:37:39AM -0700, Andy Lutomirski wrote:
> But if we OOPS, we'll OOPS after the lockdep splat and the lockdep
> splat will scroll off the screen, right? Am I missing something here?
No, you're not.
> notify_die is called before the actual OOPS code is invoked in traps.c.
On Mon, Jun 22, 2015 at 10:24 AM, Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 10:03:30AM -0700, Andy Lutomirski wrote:
>> The rcu_lockdep_assert should be merely a warning, not a full OOPS.
>
> It is still pretty huge, see below.
>
>> I think that, if rcu_lockdep_assert hangs, then we should
On Mon, Jun 22, 2015 at 10:03:30AM -0700, Andy Lutomirski wrote:
> The rcu_lockdep_assert should be merely a warning, not a full OOPS.
It is still pretty huge, see below.
> I think that, if rcu_lockdep_assert hangs, then we should fix that
> rather than avoiding debugging checks.
The RCU asserti
On Mon, Jun 22, 2015 at 9:33 AM, Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 09:26:13AM -0700, Andy Lutomirski wrote:
>> notify_die is misnamed and has little to do with death. It's really
>> just notifying about an exception, and we might end up oopsing,
>> sending a signal, or neither.
>
>
On Mon, Jun 22, 2015 at 09:26:13AM -0700, Andy Lutomirski wrote:
> notify_die is misnamed and has little to do with death. It's really
> just notifying about an exception, and we might end up oopsing,
> sending a signal, or neither.
But if we oops and wedge solid afterwards, it might happen that o
On Jun 22, 2015 4:37 AM, "Borislav Petkov" wrote:
>
> On Thu, Jun 18, 2015 at 12:08:35PM -0700, Andy Lutomirski wrote:
> > Low-level arch entries often call notify_die, and it's easy for arch
> > code to fail to exit an RCU quiescent state first. Assert that
> > we're not quiescent in notify_die.
On Thu, Jun 18, 2015 at 12:08:35PM -0700, Andy Lutomirski wrote:
> Low-level arch entries often call notify_die, and it's easy for arch
> code to fail to exit an RCU quiescent state first. Assert that
> we're not quiescent in notify_die.
>
> Signed-off-by: Andy Lutomirski
> ---
> kernel/notifie
Low-level arch entries often call notify_die, and it's easy for arch
code to fail to exit an RCU quiescent state first. Assert that
we're not quiescent in notify_die.
Signed-off-by: Andy Lutomirski
---
kernel/notifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/notifier.c b/k
11 matches
Mail list logo
