All of lore.kernel.org
 help / color / mirror / Atom feed
From: grygorii.strashko@ti.com (Grygorii Strashko)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-next][regression] [PATCH] percpu: add preemption checks to __this_cpu ops
Date: Wed, 19 Mar 2014 13:18:52 +0200	[thread overview]
Message-ID: <53297D1C.3000100@ti.com> (raw)
In-Reply-To: <20140318143759.04a892434d84a9fd3aa94262@linux-foundation.org>

On 03/18/2014 11:37 PM, Andrew Morton wrote:> On Tue, 18 Mar 2014 10:54:06 -0500 (CDT) Christoph Lameter <cl@linux.com> wrote:
> 
>> On Tue, 18 Mar 2014, Grygorii Strashko wrote:
>>
>>> Any way, I can boot and console works fine with your change :)
>>> Thanks.
>>
>> Ok here is the properly formatted patch:
>>
>>
>> Subject: preemption_checks: Avoid snprintf before checking error conditions
>>
>> snprintf can cause hangs.
> 
> This is weird.  How the heck can snprintf() fail if called too early?
> All it does is shuffle chars around in memory.  The only external
> dependency I'm seeing is a WARN_ON() which presumably didn't trigger
> anyway.
> 
> I'm suspecting a misdiagnosis here.  Otherwise, we seriously need to
> fix snprintf(), not work around it!

Not sure I can run debugger fast :(, but I'll try.

> 
> Also, what does "before checking error conditions" refer to?  Does this
> mean you know why snprintf() failed??

Just an assumption, May be the problem here not in snprintf, but in stack.
Looks like if I reduce stack usage the issue is gone:
char text[10];

> 
>> Move the string processing into the function
>> so that the string operations only occur when necessary after the
>> conditions have been checked.
>>
>> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
> 
> Grygorii, thanks for testing linux-next on unusual machines - it's most
> helpful.
> 

Regards,
-grygorii

WARNING: multiple messages have this Message-ID (diff)
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@linux.com>
Cc: linux-arm <linux-arm-kernel@lists.infradead.org>,
	Tejun Heo <tj@kernel.org>, <linux-kernel@vger.kernel.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [linux-next][regression] [PATCH] percpu: add preemption checks to __this_cpu ops
Date: Wed, 19 Mar 2014 13:18:52 +0200	[thread overview]
Message-ID: <53297D1C.3000100@ti.com> (raw)
In-Reply-To: <20140318143759.04a892434d84a9fd3aa94262@linux-foundation.org>

On 03/18/2014 11:37 PM, Andrew Morton wrote:> On Tue, 18 Mar 2014 10:54:06 -0500 (CDT) Christoph Lameter <cl@linux.com> wrote:
> 
>> On Tue, 18 Mar 2014, Grygorii Strashko wrote:
>>
>>> Any way, I can boot and console works fine with your change :)
>>> Thanks.
>>
>> Ok here is the properly formatted patch:
>>
>>
>> Subject: preemption_checks: Avoid snprintf before checking error conditions
>>
>> snprintf can cause hangs.
> 
> This is weird.  How the heck can snprintf() fail if called too early?
> All it does is shuffle chars around in memory.  The only external
> dependency I'm seeing is a WARN_ON() which presumably didn't trigger
> anyway.
> 
> I'm suspecting a misdiagnosis here.  Otherwise, we seriously need to
> fix snprintf(), not work around it!

Not sure I can run debugger fast :(, but I'll try.

> 
> Also, what does "before checking error conditions" refer to?  Does this
> mean you know why snprintf() failed??

Just an assumption, May be the problem here not in snprintf, but in stack.
Looks like if I reduce stack usage the issue is gone:
char text[10];

> 
>> Move the string processing into the function
>> so that the string operations only occur when necessary after the
>> conditions have been checked.
>>
>> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
> 
> Grygorii, thanks for testing linux-next on unusual machines - it's most
> helpful.
> 

Regards,
-grygorii

  reply	other threads:[~2014-03-19 11:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 15:01 [linux-next][regression] [PATCH] percpu: add preemption checks to __this_cpu ops Grygorii Strashko
2014-03-18 15:01 ` Grygorii Strashko
2014-03-18 14:37 ` Christoph Lameter
2014-03-18 14:37   ` Christoph Lameter
2014-03-18 15:48   ` Grygorii Strashko
2014-03-18 15:48     ` Grygorii Strashko
2014-03-18 15:54     ` Christoph Lameter
2014-03-18 15:54       ` Christoph Lameter
2014-03-18 21:37       ` Andrew Morton
2014-03-18 21:37         ` Andrew Morton
2014-03-19 11:18         ` Grygorii Strashko [this message]
2014-03-19 11:18           ` Grygorii Strashko
2014-03-20 14:06         ` Christoph Lameter
2014-03-20 14:06           ` Christoph Lameter
2014-04-14 17:17 ` [3.15-rc1] a huge number of warnings produced by xhci & Grygorii Strashko
2014-04-14 17:12   ` Christoph Lameter
2014-04-14 17:12     ` Christoph Lameter
2014-04-15 10:00     ` Grygorii Strashko
2014-04-15 10:00       ` Grygorii Strashko

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=53297D1C.3000100@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.