All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Oza (Pawandeep) Oza" <oza@broadcom.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: pawandeep oza <oza.contri.linux.kernel@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	malayasen rout <malayasen.rout@gmail.com>
Subject: RE: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17
Date: Fri, 8 May 2015 04:16:19 +0000	[thread overview]
Message-ID: <5C6899BCED92C94EBDCC00F80838E3D52113AB15@SJEXCHMB06.corp.ad.broadcom.com> (raw)
In-Reply-To: 1430987391.2955.163.camel@gmail.com

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

So Mike, is this reason strong enough for you ?

I understand your point: solve the BUG, and I do tend to agree with you.

But by design and implementation, the BUG() is just a beginning of the end for dying kernel.
And what happens in between this 'the beginning' and 'the end' is not less important. 
(because say,  on our platform we want to get clean RAMDUMP to analyze what happened, and for that we want to get clean reboot)

Also,
If somebody's design is to legally Crash the kernel (e.g. where kernel is actually not faulty).
Then, I do expect that tick/timekeeping framework do its job as long as it can do, and it should do, because kernel is not faulty.
But in this case it doesn’t handover jiffies incrementing job sanely.

In other words, 
"no one can relies on jiffies, or rather the code which is based on jiffies will never forward progress in this path"

Regards,
-Oza


-----Original Message-----
From: Oza (Pawandeep) Oza 
Sent: Thursday, May 07, 2015 2:17 PM
To: 'Mike Galbraith'
Cc: pawandeep oza; linux-kernel@vger.kernel.org; malayasen rout
Subject: RE: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

Oh ok.
So the reason why I cared was:

There is a code in our base which relies on jiffies, but since jiffies are not incrementing, the code waits there and loops forever.
And forward progress is on halt. (on cpu0, since that is the only cpu, which is alive)

We have changed the code to use mdelay and things move on.

But that means that in the patch which I mentioned, 
any code which relies on jiffies will stuck forever and will not allow rest of the code to get executed and hence no forward progress.
specially if that code is running with preempt_disable();

Regards,
-Oza


-----Original Message-----
From: Mike Galbraith [mailto:umgwanakikbuti@gmail.com] 
Sent: Thursday, May 07, 2015 2:00 PM
To: Oza (Pawandeep) Oza
Cc: pawandeep oza; linux-kernel@vger.kernel.org; malayasen rout
Subject: Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

On Thu, 2015-05-07 at 07:05 +0000, Oza (Pawandeep) Oza wrote:
> : )
> 
> Well, I am not sure, if problem was communicated clearly from my side.

I understood.  I just don't understand why you'd care deeply whether
CPU0 halts or eternally waits.  Both render it harmless and useless.

	-Mike

ÿôèº{.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¥

  parent reply	other threads:[~2015-05-08  4:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 17:27 [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17 pawandeep oza
2015-05-07  3:22 ` Mike Galbraith
2015-05-07  4:37   ` Oza (Pawandeep) Oza
2015-05-07  5:08     ` Mike Galbraith
2015-05-07  5:12       ` Oza (Pawandeep) Oza
2015-05-07  5:54         ` Mike Galbraith
2015-05-07  5:58           ` Oza (Pawandeep) Oza
2015-05-07  6:54             ` Mike Galbraith
2015-05-07  7:05               ` Oza (Pawandeep) Oza
2015-05-07  8:29                 ` Mike Galbraith
2015-05-07  8:47                   ` Oza (Pawandeep) Oza
2015-05-08  4:16                   ` Oza (Pawandeep) Oza [this message]
2015-05-08  5:12                     ` Mike Galbraith
2015-05-08  5:21                       ` Oza (Pawandeep) Oza
2015-05-07  8:19               ` Oza (Pawandeep) Oza

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=5C6899BCED92C94EBDCC00F80838E3D52113AB15@SJEXCHMB06.corp.ad.broadcom.com \
    --to=oza@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malayasen.rout@gmail.com \
    --cc=oza.contri.linux.kernel@gmail.com \
    --cc=umgwanakikbuti@gmail.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 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.