from:"long.wanglong"

On 2015/9/25 4:02, Bird, Tim wrote:
> On Wednesday, September 23, 2015 8:26 PM, long.wanglong 
> [long.wangl...@huawei.com] wrote:
>>
>> Hi, tim
>>
>> Could you help me with the following problem?
>>
>> On my x86_64 system, I can not compile the size kselftest, the output is:
>>
>> for TARGET in size; do \
>> make -C $TARGET; \
>> done;
>> make[2]: Entering directory 
>> `/home/wanglong/linux-mainline/tools/testing/selftests/size'
>> gcc -static -ffreestanding -nostartfiles -s get_size.c -o get_size
>> /usr/bin/ld: cannot find -lc
>> collect2: error: ld returned 1 exit status
>> make[2]: *** [get_size] Error 1
>> make[2]: Leaving directory 
>> `/home/wanglong/linux-mainline/tools/testing/selftests/size'
>> make[1]: *** [all] Error 2
>> make: *** [kselftest] Error 2
>>
>>
>> But, with the following command:
>> # cd tools/testing/selftests/size
>> # gcc -ffreestanding -nostartfiles -s get_size.c -o get_size
>> its ok.
>>
>> My GCC is:
>>
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
>> Target: x86_64-redhat-linux
>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
>> --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
>> --enable-bootstrap --enable-shared --enable-threads=posix 
>> --enable-checking=release --with-system-zlib --enable-__cxa_atexit 
>> --disable-libunwind-exceptions --enable-gnu-unique-object 
>> --enable-linker-build-id --with-linker-hash-style=gnu 
>> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto 
>> --enable-plugin --enable-initfini-array --disable-libgcj 
>> --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
>>  
>> --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
>>  --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
>> --build=x86_64-redhat-linux
>> Thread model: posix
>> gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
>>
>>
>> I google  `/usr/bin/ld: cannot find -lc`, but it did not help me more.
>>
>> Could you please help me?
> 
> The problem is that you are missing the version of the C library for static 
> linking.  This should be in one of
> your C library directories, with the name libc.a (not libc.so, which is the 
> shared object library for dynamic linking).
> Sometimes the static libraries are built as separate packages. 
> 
> 
> It looks like you need to install the 'glibc-static' development package.
> 
> See 
> http://rpmfind.net//linux/RPM/fedora/devel/rawhide/x86_64/g/glibc-static-2.22.90-6.fc24.x86_64.html
> 
> Let me know if that solves the problem for you (or not).
>  -- Tim

Hi Tim,

Thanks for you reply.

The reason I can not compile successfully is that, so far, the kselftests does 
not support -O option.

When I compile kernel without -O option, the size unit test can compile 
successfully.

so I hope the kselftests will support standard kernel options:

1）Separate out directory （KBUILD_OUTPUT support）
2）Verbose vs quiet building （V=1 support）

Best Regards
Wang Long

> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

On 2015/9/25 23:44, Darren Hart wrote:
> On Thu, Sep 24, 2015 at 12:07:47PM +1000, Michael Ellerman wrote:
>> On Thu, 2015-09-24 at 10:05 +0800, long.wanglong wrote:
>>> On 2015/9/24 9:46, Michael Ellerman wrote:
>>>> On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
>>>>> Use make's built-in rules to when delete a file
>>>>> or delete files.
>>>>
>>>> It's not a built-in rule, it's a variable.
>>>
>>> Sorry，I did not describe clearly. It is a variable used as
>>> name of program in built-in rules.
>>>
>>>> Personally I think using rm directly is clearer, but I guess this is fine. 
>>>> Do
>>>> you actually want to override $RM ?
>>>
>>> So far, I do not want to override $(RM). But I found that some test's 
>>> Makefile
>>> using *$(RM)* while the other's using *rm -f*, I think it is better to use 
>>> one
>>> of them in all unit tests.
> 
> Agreed, consistency is good.
> 
>>>
>>> Do you think which one is better?
>>
>> I prefer just using rm -f, because it's less magic, everyone knows what it 
>> does.
>>
> 
> Also agreed, it's explicit and perfectly functional.
> 
Ok, thanks, I will send another patch to replace $(RM) with "rm -f".

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

On 2015/9/25 23:44, Darren Hart wrote:
> On Thu, Sep 24, 2015 at 12:07:47PM +1000, Michael Ellerman wrote:
>> On Thu, 2015-09-24 at 10:05 +0800, long.wanglong wrote:
>>> On 2015/9/24 9:46, Michael Ellerman wrote:
>>>> On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
>>>>> Use make's built-in rules to when delete a file
>>>>> or delete files.
>>>>
>>>> It's not a built-in rule, it's a variable.
>>>
>>> Sorry，I did not describe clearly. It is a variable used as
>>> name of program in built-in rules.
>>>
>>>> Personally I think using rm directly is clearer, but I guess this is fine. 
>>>> Do
>>>> you actually want to override $RM ?
>>>
>>> So far, I do not want to override $(RM). But I found that some test's 
>>> Makefile
>>> using *$(RM)* while the other's using *rm -f*, I think it is better to use 
>>> one
>>> of them in all unit tests.
> 
> Agreed, consistency is good.
> 
>>>
>>> Do you think which one is better?
>>
>> I prefer just using rm -f, because it's less magic, everyone knows what it 
>> does.
>>
> 
> Also agreed, it's explicit and perfectly functional.
> 
Ok, thanks, I will send another patch to replace $(RM) with "rm -f".

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can you give me a suggestion for how to compile size kselftest?

On 2015/9/25 4:02, Bird, Tim wrote:
> On Wednesday, September 23, 2015 8:26 PM, long.wanglong 
> [long.wangl...@huawei.com] wrote:
>>
>> Hi, tim
>>
>> Could you help me with the following problem?
>>
>> On my x86_64 system, I can not compile the size kselftest, the output is:
>>
>> for TARGET in size; do \
>> make -C $TARGET; \
>> done;
>> make[2]: Entering directory 
>> `/home/wanglong/linux-mainline/tools/testing/selftests/size'
>> gcc -static -ffreestanding -nostartfiles -s get_size.c -o get_size
>> /usr/bin/ld: cannot find -lc
>> collect2: error: ld returned 1 exit status
>> make[2]: *** [get_size] Error 1
>> make[2]: Leaving directory 
>> `/home/wanglong/linux-mainline/tools/testing/selftests/size'
>> make[1]: *** [all] Error 2
>> make: *** [kselftest] Error 2
>>
>>
>> But, with the following command:
>> # cd tools/testing/selftests/size
>> # gcc -ffreestanding -nostartfiles -s get_size.c -o get_size
>> its ok.
>>
>> My GCC is:
>>
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
>> Target: x86_64-redhat-linux
>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
>> --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
>> --enable-bootstrap --enable-shared --enable-threads=posix 
>> --enable-checking=release --with-system-zlib --enable-__cxa_atexit 
>> --disable-libunwind-exceptions --enable-gnu-unique-object 
>> --enable-linker-build-id --with-linker-hash-style=gnu 
>> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto 
>> --enable-plugin --enable-initfini-array --disable-libgcj 
>> --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
>>  
>> --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
>>  --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
>> --build=x86_64-redhat-linux
>> Thread model: posix
>> gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
>>
>>
>> I google  `/usr/bin/ld: cannot find -lc`, but it did not help me more.
>>
>> Could you please help me?
> 
> The problem is that you are missing the version of the C library for static 
> linking.  This should be in one of
> your C library directories, with the name libc.a (not libc.so, which is the 
> shared object library for dynamic linking).
> Sometimes the static libraries are built as separate packages. 
> 
> 
> It looks like you need to install the 'glibc-static' development package.
> 
> See 
> http://rpmfind.net//linux/RPM/fedora/devel/rawhide/x86_64/g/glibc-static-2.22.90-6.fc24.x86_64.html
> 
> Let me know if that solves the problem for you (or not).
>  -- Tim

Hi Tim,

Thanks for you reply.

The reason I can not compile successfully is that, so far, the kselftests does 
not support -O option.

When I compile kernel without -O option, the size unit test can compile 
successfully.

so I hope the kselftests will support standard kernel options:

1）Separate out directory （KBUILD_OUTPUT support）
2）Verbose vs quiet building （V=1 support）

Best Regards
Wang Long

> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

2015-09-23 Thread long.wanglong

On 2015/9/24 9:46, Michael Ellerman wrote:
> On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
>> Use make's built-in rules to when delete a file
>> or delete files.
> 
> It's not a built-in rule, it's a variable.

Sorry，I did not describe clearly. It is a variable used as
name of program in built-in rules.

> 
> Personally I think using rm directly is clearer, but I guess this is fine. Do
> you actually want to override $RM ?
> 

So far, I do not want to override $(RM). But I found that some test's Makefile
using *$(RM)* while the other's using *rm -f*, I think it is better to use one
of them in all unit tests.

Do you think which one is better?

Best Regards
Wang Long

> cheers
> 
> 
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

2015-09-23 Thread long.wanglong

On 2015/9/24 9:46, Michael Ellerman wrote:
> On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
>> Use make's built-in rules to when delete a file
>> or delete files.
> 
> It's not a built-in rule, it's a variable.

Sorry，I did not describe clearly. It is a variable used as
name of program in built-in rules.

> 
> Personally I think using rm directly is clearer, but I guess this is fine. Do
> you actually want to override $RM ?
> 

So far, I do not want to override $(RM). But I found that some test's Makefile
using *$(RM)* while the other's using *rm -f*, I think it is better to use one
of them in all unit tests.

Do you think which one is better?

Best Regards
Wang Long

> cheers
> 
> 
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] kasan: Fix a type conversion error

On 2015/9/9 17:40, Andrey Ryabinin wrote:
> 2015-09-09 6:59 GMT+03:00 Wang Long :
>> The current KASAN code can find the following out-of-bounds
>> bugs:
>> char *ptr;
>> ptr = kmalloc(8, GFP_KERNEL);
>> memset(ptr+7, 0, 2);
>>
>> the cause of the problem is the type conversion error in
>> *memory_is_poisoned_n* function. So this patch fix that.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  mm/kasan/kasan.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>> index 7b28e9c..5d65d06 100644
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -204,7 +204,7 @@ static __always_inline bool 
>> memory_is_poisoned_n(unsigned long addr,
>> s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void 
>> *)last_byte);
>>
>> if (unlikely(ret != (unsigned long)last_shadow ||
>> -   ((last_byte & KASAN_SHADOW_MASK) >= *last_shadow)))
>> +   ((long)(last_byte & KASAN_SHADOW_MASK) >= 
>> *last_shadow)))
> 
> Is there any problem if we just define last_byte as 'long' instead of
> 'unsigned long' ?

yes, I think it is not OK, because on my test, if we define last_byte as 'long'
instead of 'unsigned long', the bug we talk about can not be found.


> 
>> return true;
>> }
>> return false;
>> --
>> 1.8.3.4
>>
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] kasan: Fix a type conversion error

On 2015/9/9 17:01, Vladimir Murzin wrote:
> On 09/09/15 04:59, Wang Long wrote:
>> The current KASAN code can find the following out-of-bounds
> 
> Should it be "cannot"?
> 
> Vladimir
> 
sorry for that mistake, it should be "cannot".

>> bugs:
>>  char *ptr;
>>  ptr = kmalloc(8, GFP_KERNEL);
>>  memset(ptr+7, 0, 2);
>>
>> the cause of the problem is the type conversion error in
>> *memory_is_poisoned_n* function. So this patch fix that.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  mm/kasan/kasan.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>> index 7b28e9c..5d65d06 100644
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -204,7 +204,7 @@ static __always_inline bool 
>> memory_is_poisoned_n(unsigned long addr,
>>  s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void *)last_byte);
>>  
>>  if (unlikely(ret != (unsigned long)last_shadow ||
>> -((last_byte & KASAN_SHADOW_MASK) >= *last_shadow)))
>> +((long)(last_byte & KASAN_SHADOW_MASK) >= 
>> *last_shadow)))
>>  return true;
>>  }
>>  return false;
>>
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] kasan: fix last shadow judgement in memory_is_poisoned_16()

On 2015/9/9 15:43, Xishi Qiu wrote:
> On 2015/9/9 14:40, long.wanglong wrote:
> 
>> On 2015/9/8 20:12, Xishi Qiu wrote:
>>> The shadow which correspond 16 bytes memory may span 2 or 3 bytes. If the
>>> memory is aligned on 8, then the shadow takes only 2 bytes. So we check
>>> "shadow_first_bytes" is enough, and need not to call 
>>> "memory_is_poisoned_1(addr + 15);".
>>> But the code "if (likely(!last_byte))" is wrong judgement.
>>>
>>> e.g. addr=0, so last_byte = 15 & KASAN_SHADOW_MASK = 7, then the code will
>>> continue to call "memory_is_poisoned_1(addr + 15);"
>>>
>>> Signed-off-by: Xishi Qiu 
>>> ---
>>>  mm/kasan/kasan.c |3 +--
>>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>>> index 7b28e9c..8da2114 100644
>>> --- a/mm/kasan/kasan.c
>>> +++ b/mm/kasan/kasan.c
>>> @@ -135,12 +135,11 @@ static __always_inline bool 
>>> memory_is_poisoned_16(unsigned long addr)
>>>  
>>> if (unlikely(*shadow_addr)) {
>>> u16 shadow_first_bytes = *(u16 *)shadow_addr;
>>> -   s8 last_byte = (addr + 15) & KASAN_SHADOW_MASK;
>>>  
>>> if (unlikely(shadow_first_bytes))
>>> return true;
>>>  
>>> -   if (likely(!last_byte))
>>> +   if (likely(IS_ALIGNED(addr, 8)))
>>> return false;
>>>  
>>> return memory_is_poisoned_1(addr + 15);
>>>
>>
>> Hi,
>> I also notice this problem, how about another method to fix it:
>>
>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>> index 5d65d06..6a20dda 100644
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -140,7 +140,7 @@ static __always_inline bool 
>> memory_is_poisoned_16(unsigned long addr)
>> if (unlikely(shadow_first_bytes))
>> return true;
>>
>> -   if (likely(!last_byte))
>> +   if (likely(last_byte >= 7))
>> return false;
>>
>> return memory_is_poisoned_1(addr + 15);
>>
>> This method can ensure consistency of code, for example, in 
>> memory_is_poisoned_8:
>>
>> static __always_inline bool memory_is_poisoned_8(unsigned long addr)
>> {
>> u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
>>
>> if (unlikely(*shadow_addr)) {
>> if (memory_is_poisoned_1(addr + 7))
>> return true;
>>
>> if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
>> return false;
>>
>> return unlikely(*(u8 *)shadow_addr);
>> }
>>
>> return false;
>> }
>>
>> Otherwise, we also should use IS_ALIGNED macro in memory_is_poisoned_8!
>>
> 
> Hi Wanglong,
> 
> How about use IS_ALIGNED instead of those code in memory_is_poisoned_8()
> and other functions? I think the current code looks a bit ugly.
> 

I think we can use  IS_ALIGNED macro in memory_is_poisoned_8 and 
memory_is_poisoned_16.
but for functions memory_is_poisoned_2 and memory_is_poisoned_4, we can't.

Wang Long


> Thanks,
> Xishi Qiu
> 
>>
>> Best Regards
>> Wang Long
>>
>>
>>
>>
>>
>> .
>>
> 
> 
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] kasan: fix last shadow judgement in memory_is_poisoned_16()

On 2015/9/8 20:12, Xishi Qiu wrote:
> The shadow which correspond 16 bytes memory may span 2 or 3 bytes. If the
> memory is aligned on 8, then the shadow takes only 2 bytes. So we check
> "shadow_first_bytes" is enough, and need not to call 
> "memory_is_poisoned_1(addr + 15);".
> But the code "if (likely(!last_byte))" is wrong judgement.
> 
> e.g. addr=0, so last_byte = 15 & KASAN_SHADOW_MASK = 7, then the code will
> continue to call "memory_is_poisoned_1(addr + 15);"
> 
> Signed-off-by: Xishi Qiu 
> ---
>  mm/kasan/kasan.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index 7b28e9c..8da2114 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -135,12 +135,11 @@ static __always_inline bool 
> memory_is_poisoned_16(unsigned long addr)
>  
>   if (unlikely(*shadow_addr)) {
>   u16 shadow_first_bytes = *(u16 *)shadow_addr;
> - s8 last_byte = (addr + 15) & KASAN_SHADOW_MASK;
>  
>   if (unlikely(shadow_first_bytes))
>   return true;
>  
> - if (likely(!last_byte))
> + if (likely(IS_ALIGNED(addr, 8)))
>   return false;
>  
>   return memory_is_poisoned_1(addr + 15);
> 

Hi,
I also notice this problem, how about another method to fix it:

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 5d65d06..6a20dda 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -140,7 +140,7 @@ static __always_inline bool memory_is_poisoned_16(unsigned 
long addr)
if (unlikely(shadow_first_bytes))
return true;

-   if (likely(!last_byte))
+   if (likely(last_byte >= 7))
return false;

return memory_is_poisoned_1(addr + 15);

This method can ensure consistency of code, for example, in 
memory_is_poisoned_8:

static __always_inline bool memory_is_poisoned_8(unsigned long addr)
{
u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);

if (unlikely(*shadow_addr)) {
if (memory_is_poisoned_1(addr + 7))
return true;

if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
return false;

return unlikely(*(u8 *)shadow_addr);
}

return false;
}

Otherwise, we also should use IS_ALIGNED macro in memory_is_poisoned_8!


Best Regards
Wang Long




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] kasan: fix last shadow judgement in memory_is_poisoned_16()

On 2015/9/8 20:12, Xishi Qiu wrote:
> The shadow which correspond 16 bytes memory may span 2 or 3 bytes. If the
> memory is aligned on 8, then the shadow takes only 2 bytes. So we check
> "shadow_first_bytes" is enough, and need not to call 
> "memory_is_poisoned_1(addr + 15);".
> But the code "if (likely(!last_byte))" is wrong judgement.
> 
> e.g. addr=0, so last_byte = 15 & KASAN_SHADOW_MASK = 7, then the code will
> continue to call "memory_is_poisoned_1(addr + 15);"
> 
> Signed-off-by: Xishi Qiu 
> ---
>  mm/kasan/kasan.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index 7b28e9c..8da2114 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -135,12 +135,11 @@ static __always_inline bool 
> memory_is_poisoned_16(unsigned long addr)
>  
>   if (unlikely(*shadow_addr)) {
>   u16 shadow_first_bytes = *(u16 *)shadow_addr;
> - s8 last_byte = (addr + 15) & KASAN_SHADOW_MASK;
>  
>   if (unlikely(shadow_first_bytes))
>   return true;
>  
> - if (likely(!last_byte))
> + if (likely(IS_ALIGNED(addr, 8)))
>   return false;
>  
>   return memory_is_poisoned_1(addr + 15);
> 

Hi,
I also notice this problem, how about another method to fix it:

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 5d65d06..6a20dda 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -140,7 +140,7 @@ static __always_inline bool memory_is_poisoned_16(unsigned 
long addr)
if (unlikely(shadow_first_bytes))
return true;

-   if (likely(!last_byte))
+   if (likely(last_byte >= 7))
return false;

return memory_is_poisoned_1(addr + 15);

This method can ensure consistency of code, for example, in 
memory_is_poisoned_8:

static __always_inline bool memory_is_poisoned_8(unsigned long addr)
{
u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);

if (unlikely(*shadow_addr)) {
if (memory_is_poisoned_1(addr + 7))
return true;

if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
return false;

return unlikely(*(u8 *)shadow_addr);
}

return false;
}

Otherwise, we also should use IS_ALIGNED macro in memory_is_poisoned_8!


Best Regards
Wang Long




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] kasan: fix last shadow judgement in memory_is_poisoned_16()

On 2015/9/9 15:43, Xishi Qiu wrote:
> On 2015/9/9 14:40, long.wanglong wrote:
> 
>> On 2015/9/8 20:12, Xishi Qiu wrote:
>>> The shadow which correspond 16 bytes memory may span 2 or 3 bytes. If the
>>> memory is aligned on 8, then the shadow takes only 2 bytes. So we check
>>> "shadow_first_bytes" is enough, and need not to call 
>>> "memory_is_poisoned_1(addr + 15);".
>>> But the code "if (likely(!last_byte))" is wrong judgement.
>>>
>>> e.g. addr=0, so last_byte = 15 & KASAN_SHADOW_MASK = 7, then the code will
>>> continue to call "memory_is_poisoned_1(addr + 15);"
>>>
>>> Signed-off-by: Xishi Qiu <qiuxi...@huawei.com>
>>> ---
>>>  mm/kasan/kasan.c |3 +--
>>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>>> index 7b28e9c..8da2114 100644
>>> --- a/mm/kasan/kasan.c
>>> +++ b/mm/kasan/kasan.c
>>> @@ -135,12 +135,11 @@ static __always_inline bool 
>>> memory_is_poisoned_16(unsigned long addr)
>>>  
>>> if (unlikely(*shadow_addr)) {
>>> u16 shadow_first_bytes = *(u16 *)shadow_addr;
>>> -   s8 last_byte = (addr + 15) & KASAN_SHADOW_MASK;
>>>  
>>> if (unlikely(shadow_first_bytes))
>>> return true;
>>>  
>>> -   if (likely(!last_byte))
>>> +   if (likely(IS_ALIGNED(addr, 8)))
>>> return false;
>>>  
>>> return memory_is_poisoned_1(addr + 15);
>>>
>>
>> Hi,
>> I also notice this problem, how about another method to fix it:
>>
>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>> index 5d65d06..6a20dda 100644
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -140,7 +140,7 @@ static __always_inline bool 
>> memory_is_poisoned_16(unsigned long addr)
>> if (unlikely(shadow_first_bytes))
>> return true;
>>
>> -   if (likely(!last_byte))
>> +   if (likely(last_byte >= 7))
>> return false;
>>
>> return memory_is_poisoned_1(addr + 15);
>>
>> This method can ensure consistency of code, for example, in 
>> memory_is_poisoned_8:
>>
>> static __always_inline bool memory_is_poisoned_8(unsigned long addr)
>> {
>> u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
>>
>> if (unlikely(*shadow_addr)) {
>> if (memory_is_poisoned_1(addr + 7))
>> return true;
>>
>> if (likely(((addr + 7) & KASAN_SHADOW_MASK) >= 7))
>> return false;
>>
>> return unlikely(*(u8 *)shadow_addr);
>> }
>>
>> return false;
>> }
>>
>> Otherwise, we also should use IS_ALIGNED macro in memory_is_poisoned_8!
>>
> 
> Hi Wanglong,
> 
> How about use IS_ALIGNED instead of those code in memory_is_poisoned_8()
> and other functions? I think the current code looks a bit ugly.
> 

I think we can use  IS_ALIGNED macro in memory_is_poisoned_8 and 
memory_is_poisoned_16.
but for functions memory_is_poisoned_2 and memory_is_poisoned_4, we can't.

Wang Long


> Thanks,
> Xishi Qiu
> 
>>
>> Best Regards
>> Wang Long
>>
>>
>>
>>
>>
>> .
>>
> 
> 
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] kasan: Fix a type conversion error

On 2015/9/9 17:40, Andrey Ryabinin wrote:
> 2015-09-09 6:59 GMT+03:00 Wang Long :
>> The current KASAN code can find the following out-of-bounds
>> bugs:
>> char *ptr;
>> ptr = kmalloc(8, GFP_KERNEL);
>> memset(ptr+7, 0, 2);
>>
>> the cause of the problem is the type conversion error in
>> *memory_is_poisoned_n* function. So this patch fix that.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  mm/kasan/kasan.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>> index 7b28e9c..5d65d06 100644
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -204,7 +204,7 @@ static __always_inline bool 
>> memory_is_poisoned_n(unsigned long addr,
>> s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void 
>> *)last_byte);
>>
>> if (unlikely(ret != (unsigned long)last_shadow ||
>> -   ((last_byte & KASAN_SHADOW_MASK) >= *last_shadow)))
>> +   ((long)(last_byte & KASAN_SHADOW_MASK) >= 
>> *last_shadow)))
> 
> Is there any problem if we just define last_byte as 'long' instead of
> 'unsigned long' ?

yes, I think it is not OK, because on my test, if we define last_byte as 'long'
instead of 'unsigned long', the bug we talk about can not be found.


> 
>> return true;
>> }
>> return false;
>> --
>> 1.8.3.4
>>
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] kasan: Fix a type conversion error

On 2015/9/9 17:01, Vladimir Murzin wrote:
> On 09/09/15 04:59, Wang Long wrote:
>> The current KASAN code can find the following out-of-bounds
> 
> Should it be "cannot"?
> 
> Vladimir
> 
sorry for that mistake, it should be "cannot".

>> bugs:
>>  char *ptr;
>>  ptr = kmalloc(8, GFP_KERNEL);
>>  memset(ptr+7, 0, 2);
>>
>> the cause of the problem is the type conversion error in
>> *memory_is_poisoned_n* function. So this patch fix that.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  mm/kasan/kasan.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
>> index 7b28e9c..5d65d06 100644
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -204,7 +204,7 @@ static __always_inline bool 
>> memory_is_poisoned_n(unsigned long addr,
>>  s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void *)last_byte);
>>  
>>  if (unlikely(ret != (unsigned long)last_shadow ||
>> -((last_byte & KASAN_SHADOW_MASK) >= *last_shadow)))
>> +((long)(last_byte & KASAN_SHADOW_MASK) >= 
>> *last_shadow)))
>>  return true;
>>  }
>>  return false;
>>
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/of/fdt.c: replace pr_warning by pr_warn

2015-07-26 Thread long.wanglong

On 2015/7/27 4:39, Rob Herring wrote:
> On Fri, Jul 24, 2015 at 7:57 PM, long.wanglong  
> wrote:
>> On 2015/7/25 3:00, Rob Herring wrote:
>>> On Tue, Jul 21, 2015 at 3:01 AM, Wang Long  wrote:
>>>> Update the last pr_warning callsite in drivers/of.
>>>
>>> That is obvious in the diff, but can you tell me why?
>>
>> Hi Rob,
>>
>> When we use script "./scripts/checkpatch.pl" to check a patch, using 
>> pr_warning
>> will produce WARNING:
>>
>> WARNING: Prefer pr_warn(... to pr_warning(...
>> #22: FILE: drivers/of/fdt.c:428:
>> +   pr_warning("End of tree marker overwritten: %08x\n",
>>
>> So,we should convert pr_warning to pr_warn.
> 
> Okay, but don't explain to me. Explain this in the commit message.
> 
> Rob
> 
> 

OK, i will send another patch and explain this in the commit message.

Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/of/fdt.c: replace pr_warning by pr_warn

2015-07-26 Thread long.wanglong

On 2015/7/27 4:39, Rob Herring wrote:
 On Fri, Jul 24, 2015 at 7:57 PM, long.wanglong long.wangl...@huawei.com 
 wrote:
 On 2015/7/25 3:00, Rob Herring wrote:
 On Tue, Jul 21, 2015 at 3:01 AM, Wang Long long.wangl...@huawei.com wrote:
 Update the last pr_warning callsite in drivers/of.

 That is obvious in the diff, but can you tell me why?

 Hi Rob,

 When we use script ./scripts/checkpatch.pl to check a patch, using 
 pr_warning
 will produce WARNING:

 WARNING: Prefer pr_warn(... to pr_warning(...
 #22: FILE: drivers/of/fdt.c:428:
 +   pr_warning(End of tree marker overwritten: %08x\n,

 So,we should convert pr_warning to pr_warn.
 
 Okay, but don't explain to me. Explain this in the commit message.
 
 Rob
 
 

OK, i will send another patch and explain this in the commit message.

Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/of/fdt.c: replace pr_warning by pr_warn

2015-07-24 Thread long.wanglong

On 2015/7/25 3:00, Rob Herring wrote:
> On Tue, Jul 21, 2015 at 3:01 AM, Wang Long  wrote:
>> Update the last pr_warning callsite in drivers/of.
> 
> That is obvious in the diff, but can you tell me why?

Hi Rob,

When we use script "./scripts/checkpatch.pl" to check a patch, using pr_warning
will produce WARNING:

WARNING: Prefer pr_warn(... to pr_warning(...
#22: FILE: drivers/of/fdt.c:428:
+   pr_warning("End of tree marker overwritten: %08x\n",

So,we should convert pr_warning to pr_warn.


Best Regards
Wang Long


> 
> Rob
> 
>> Signed-off-by: Wang Long 
>> ---
>>  drivers/of/fdt.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 0749656..e1f61b8 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -425,7 +425,7 @@ static void __unflatten_device_tree(const void *blob,
>> start = 0;
>> unflatten_dt_node(blob, mem, , NULL, mynodes, 0, false);
>> if (be32_to_cpup(mem + size) != 0xdeadbeef)
>> -   pr_warning("End of tree marker overwritten: %08x\n",
>> +   pr_warn("End of tree marker overwritten: %08x\n",
>>be32_to_cpup(mem + size));
>>
>> pr_debug(" <- unflatten_device_tree()\n");
>> @@ -985,24 +985,24 @@ void __init __weak early_init_dt_add_memory_arch(u64 
>> base, u64 size)
>> size &= PAGE_MASK;
>>
>> if (base > MAX_PHYS_ADDR) {
>> -   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory block 0x%llx - 0x%llx\n",
>> base, base + size);
>> return;
>> }
>>
>> if (base + size - 1 > MAX_PHYS_ADDR) {
>> -   pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory range 0x%llx - 0x%llx\n",
>> ((u64)MAX_PHYS_ADDR) + 1, base + size);
>> size = MAX_PHYS_ADDR - base + 1;
>> }
>>
>> if (base + size < phys_offset) {
>> -   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory block 0x%llx - 0x%llx\n",
>>base, base + size);
>> return;
>> }
>> if (base < phys_offset) {
>> -   pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory range 0x%llx - 0x%llx\n",
>>base, phys_offset);
>> size -= phys_offset - base;
>> base = phys_offset;
>> --
>> 1.8.3.4
>>
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/of/fdt.c: replace pr_warning by pr_warn

2015-07-24 Thread long.wanglong

On 2015/7/25 3:00, Rob Herring wrote:
 On Tue, Jul 21, 2015 at 3:01 AM, Wang Long long.wangl...@huawei.com wrote:
 Update the last pr_warning callsite in drivers/of.
 
 That is obvious in the diff, but can you tell me why?

Hi Rob,

When we use script ./scripts/checkpatch.pl to check a patch, using pr_warning
will produce WARNING:

WARNING: Prefer pr_warn(... to pr_warning(...
#22: FILE: drivers/of/fdt.c:428:
+   pr_warning(End of tree marker overwritten: %08x\n,

So,we should convert pr_warning to pr_warn.


Best Regards
Wang Long


 
 Rob
 
 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  drivers/of/fdt.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
 index 0749656..e1f61b8 100644
 --- a/drivers/of/fdt.c
 +++ b/drivers/of/fdt.c
 @@ -425,7 +425,7 @@ static void __unflatten_device_tree(const void *blob,
 start = 0;
 unflatten_dt_node(blob, mem, start, NULL, mynodes, 0, false);
 if (be32_to_cpup(mem + size) != 0xdeadbeef)
 -   pr_warning(End of tree marker overwritten: %08x\n,
 +   pr_warn(End of tree marker overwritten: %08x\n,
be32_to_cpup(mem + size));

 pr_debug( - unflatten_device_tree()\n);
 @@ -985,24 +985,24 @@ void __init __weak early_init_dt_add_memory_arch(u64 
 base, u64 size)
 size = PAGE_MASK;

 if (base  MAX_PHYS_ADDR) {
 -   pr_warning(Ignoring memory block 0x%llx - 0x%llx\n,
 +   pr_warn(Ignoring memory block 0x%llx - 0x%llx\n,
 base, base + size);
 return;
 }

 if (base + size - 1  MAX_PHYS_ADDR) {
 -   pr_warning(Ignoring memory range 0x%llx - 0x%llx\n,
 +   pr_warn(Ignoring memory range 0x%llx - 0x%llx\n,
 ((u64)MAX_PHYS_ADDR) + 1, base + size);
 size = MAX_PHYS_ADDR - base + 1;
 }

 if (base + size  phys_offset) {
 -   pr_warning(Ignoring memory block 0x%llx - 0x%llx\n,
 +   pr_warn(Ignoring memory block 0x%llx - 0x%llx\n,
base, base + size);
 return;
 }
 if (base  phys_offset) {
 -   pr_warning(Ignoring memory range 0x%llx - 0x%llx\n,
 +   pr_warn(Ignoring memory range 0x%llx - 0x%llx\n,
base, phys_offset);
 size -= phys_offset - base;
 base = phys_offset;
 --
 1.8.3.4

 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] apei/erst-dbg: Define pr_fmt macro to avoid the duplication of ERST_DBG_PFX

2015-06-16 Thread long.wanglong

On 2015/6/15 22:42, Joe Perches wrote:
> On Mon, 2015-06-15 at 09:57 +, Wang Long wrote:
>> Define pr_fmt macro with {ERST DBG: } prefix, then remove all use
>> of ERST_DBG_PFXin the pr_* functions.
> []
>> diff --git a/drivers/acpi/apei/erst-dbg.c b/drivers/acpi/apei/erst-dbg.c
> []
>> @@ -31,7 +31,8 @@
>>  
>>  #include "apei-internal.h"
>>  
>> -#define ERST_DBG_PFX"ERST DBG: "
>> +#undef pr_fmt
>> +#define pr_fmt(fmt) "ERST DBG: " fmt
> 
> Moving this #define above the first #include is what's
> generally done and doesn't require an #undef
> 
OK, Thanks

> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] apei/erst-dbg: Define pr_fmt macro to avoid the duplication of ERST_DBG_PFX

2015-06-16 Thread long.wanglong

On 2015/6/15 22:42, Joe Perches wrote:
 On Mon, 2015-06-15 at 09:57 +, Wang Long wrote:
 Define pr_fmt macro with {ERST DBG: } prefix, then remove all use
 of ERST_DBG_PFXin the pr_* functions.
 []
 diff --git a/drivers/acpi/apei/erst-dbg.c b/drivers/acpi/apei/erst-dbg.c
 []
 @@ -31,7 +31,8 @@
  
  #include apei-internal.h
  
 -#define ERST_DBG_PFXERST DBG: 
 +#undef pr_fmt
 +#define pr_fmt(fmt) ERST DBG:  fmt
 
 Moving this #define above the first #include is what's
 generally done and doesn't require an #undef
 
OK, Thanks

 
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/10] printk: Avoid deadlock in NMI + vprintk_emit() cleanup

2015-06-02 Thread long.wanglong

On 2015/6/1 21:06, Jan Kara wrote:
> On Fri 29-05-15 13:50:45, Andrew Morton wrote:
>> On Mon, 25 May 2015 14:46:23 +0200 Petr Mladek  wrote:
>>
>>> The main source of deadlocks caused by printk() in NMI context has been
>>> solved by the commit a9edc88093287 ("x86/nmi: Perform a safe NMI stack
>>> trace on all CPUs").
>>>
>>> But there are still few warnings printed in the NMI code that could
>>> case a deadlock. For example, see the freeze discussed at
>>> https://lkml.org/lkml/2015/5/20/481
>>
>> I'm not (yet) convinced that we want the entire patchset btw.  Do we
>> really want to try to semi-support printk from NMI?  With a rather
>> nasty set of hacks?
>>
>> Why not just delete the offending printks?
>   And what about WARN_ONs and BUG_ONs? Delete as well? Or just don't print
> anything when we are in NMI? I agree that NMI is so problematic context
> that restricting printk there makes some sence. OTOH propagating
> information from NMI to user is useful as well so I'm somewhat undecided.
> 
>   Honza
> 

I think that delete all printks in NMI context is not a good solution.
because some information is very useful to user.

The commit a9edc88093287 ("x86/nmi: Perform a safe NMI stack trace on all CPUs")
solved the deadlock problem only in arch_trigger_all_cpu_backtrace_handler() by
replacing the printk to a special print function (nmi_vprintk). But all the
other NMI handlers still use the original printk.

How about replacing printk function earlier? we can replace printk function
before we calling default_do_nmi(arch/x86/kernel/nmi.c) and replace back
after calling.

Is it a feasible solution? or does it introduce other problems?

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/10] printk: Avoid deadlock in NMI + vprintk_emit() cleanup

2015-06-02 Thread long.wanglong

On 2015/6/1 21:06, Jan Kara wrote:
 On Fri 29-05-15 13:50:45, Andrew Morton wrote:
 On Mon, 25 May 2015 14:46:23 +0200 Petr Mladek pmla...@suse.cz wrote:

 The main source of deadlocks caused by printk() in NMI context has been
 solved by the commit a9edc88093287 (x86/nmi: Perform a safe NMI stack
 trace on all CPUs).

 But there are still few warnings printed in the NMI code that could
 case a deadlock. For example, see the freeze discussed at
 https://lkml.org/lkml/2015/5/20/481

 I'm not (yet) convinced that we want the entire patchset btw.  Do we
 really want to try to semi-support printk from NMI?  With a rather
 nasty set of hacks?

 Why not just delete the offending printks?
   And what about WARN_ONs and BUG_ONs? Delete as well? Or just don't print
 anything when we are in NMI? I agree that NMI is so problematic context
 that restricting printk there makes some sence. OTOH propagating
 information from NMI to user is useful as well so I'm somewhat undecided.
 
   Honza
 

I think that delete all printks in NMI context is not a good solution.
because some information is very useful to user.

The commit a9edc88093287 (x86/nmi: Perform a safe NMI stack trace on all CPUs)
solved the deadlock problem only in arch_trigger_all_cpu_backtrace_handler() by
replacing the printk to a special print function (nmi_vprintk). But all the
other NMI handlers still use the original printk.

How about replacing printk function earlier? we can replace printk function
before we calling default_do_nmi(arch/x86/kernel/nmi.c) and replace back
after calling.

Is it a feasible solution? or does it introduce other problems?

Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] netevent: remove automatic variable in register_netevent_notifier()

2015-05-28 Thread long.wanglong

On 2015/5/28 22:07, Sergei Shtylyov wrote:
> Hello.
> 
> On 5/28/2015 1:00 PM, Wang Long wrote:
> 
>> Remove automatic variable 'err' in register_netevent_notifier() and
>> return the return value of atomic_notifier_chain_register() directly.
> 
>s/return value/result/, in order to avoid tautology.
> 
>> Signed-off-by: Wang Long 
> [...]
> 
> WBR, Sergei
> 
> 
> 

Thanks, I will fix that.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] netevent: remove automatic variable in register_netevent_notifier()

2015-05-28 Thread long.wanglong

On 2015/5/28 22:07, Sergei Shtylyov wrote:
 Hello.
 
 On 5/28/2015 1:00 PM, Wang Long wrote:
 
 Remove automatic variable 'err' in register_netevent_notifier() and
 return the return value of atomic_notifier_chain_register() directly.
 
s/return value/result/, in order to avoid tautology.
 
 Signed-off-by: Wang Long long.wangl...@huawei.com
 [...]
 
 WBR, Sergei
 
 
 

Thanks, I will fix that.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 00/17] [request for stable 3.10 inclusion] x86/nmi: Print all cpu stacks from NMI safely

2015-05-20 Thread long.wanglong

On 2015/5/20 21:22, Petr Mladek wrote:
> On Tue 2015-05-19 14:57:46, Petr Mladek wrote:
>> On Tue 2015-05-19 09:08:45, Wang Long wrote:
>>> This is my backport patch series to Fix the problem(backport to 3.10):
>>> "
>>> When trigger_all_cpu_backtrace() is called on x86, it will trigger an
>>> NMI on each CPU and call show_regs(). But this can lead to a hard lock
>>> up if the NMI comes in on another printk().
>>> "
>>> The solution is described in commit 
>>> "a9edc88093287183ac934be44f295f183b2c62dd":
>>> when the NMI triggers, it switches the printk routine for that CPU to call 
>>> a NMI safe printk function that records the printk in a per_cpu seq_buf 
>>> descriptor. After all NMIs have finished recording its data, the trace_
>>> seqs are printed in a safe context.
>>>
>>> The solution use "switch printk routine" and "seq_buf" infrastructures, but 
>>> the
>>> 3.10 stable have no both of them.
>>>
>>> The patch 1-13 backport the "seq_buf" infrastructures. in detail, patch 1, 2
>>> and 6 only backport "seq_buf" related code.
>>>
>>> The patch 14-15 backport the "switch printk routine".
>>>
>>> The patch 16-17 is the patch to print all cpu stacks from NMI safely
>>>
>>> as discussed in https://lkml.org/lkml/2015/5/13/497, in 3.10 stable, this 
>>> is 
>>> the only way to solve the problem and the backport code is a bit more.
>>>
>>> v1 -> v2:
>>>  * fix the indent error.
>>>  * rebase on 3.10.79
>>>
>>> Any thoughts?
>>
>> Please, wait with the integration. I am testing it with a storm of
>> sysrq requests:
>>
>> $> while true ; do echo l >/proc/sysrq-trigger ; done
>>
>> with iptables enabled:
>>
>> $> iptables -A INPUT -j LOG --log-prefix "incomming packet:"
>>
>> and storm of pings from other machine:
>>
>> $> ping -f 
>>
>>
>> The machine somehow freezes. It does not make sense. I am trying to 
>> investigate.
> 
> OK, it seems that the machine freezes because there are still few
> messages printed in the NMI context, e.g.:
> 
> [ 3080.286277] Uhhuh. NMI received for unknown reason 3d on CPU 12.
> [ 3637.939276] Uhhuh. NMI received for unknown reason 2d on CPU 13.
> 
> I am not exactly sure why I get them on the test machine. But I get
> such messages from time to time when hammering it by the pings and
> sysrq-l requests.
> 
> I modified vprintk_emit() to do raw_spin_trylock(_lock)
> and do not try to lock console in NMI context. The trylock fails
> from time to time but it does not longer freeze.
> 
> I am going to clean up the vprintk_emit() modification and send it for
> review.
> 
> Anyway, this patch set seems to work as expected. It heavily reduces
> the risk of NMI/printk-related deadlocks => it is worth having.
> 
> Feel free to use the following for the whole patchset (backport):
> 
> Reviewed-by: Petr Mladek 
> Tested-by: Petr Mladek 

Hi Greg,

This patch set is the only way to solve the NMI/printk-related deadlock 
problems.
Could you please include them to 3.10 stable?

Although the code a bit more, most of the code is "seq_buf" infrastructures and
it does not affect other parts of the kernel.


Best Regards
Wang Long

>
> 
> Best Regards,
> Petr
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 00/17] [request for stable 3.10 inclusion] x86/nmi: Print all cpu stacks from NMI safely

2015-05-20 Thread long.wanglong

On 2015/5/20 21:22, Petr Mladek wrote:
 On Tue 2015-05-19 14:57:46, Petr Mladek wrote:
 On Tue 2015-05-19 09:08:45, Wang Long wrote:
 This is my backport patch series to Fix the problem(backport to 3.10):
 
 When trigger_all_cpu_backtrace() is called on x86, it will trigger an
 NMI on each CPU and call show_regs(). But this can lead to a hard lock
 up if the NMI comes in on another printk().
 
 The solution is described in commit 
 a9edc88093287183ac934be44f295f183b2c62dd:
 when the NMI triggers, it switches the printk routine for that CPU to call 
 a NMI safe printk function that records the printk in a per_cpu seq_buf 
 descriptor. After all NMIs have finished recording its data, the trace_
 seqs are printed in a safe context.

 The solution use switch printk routine and seq_buf infrastructures, but 
 the
 3.10 stable have no both of them.

 The patch 1-13 backport the seq_buf infrastructures. in detail, patch 1, 2
 and 6 only backport seq_buf related code.

 The patch 14-15 backport the switch printk routine.

 The patch 16-17 is the patch to print all cpu stacks from NMI safely

 as discussed in https://lkml.org/lkml/2015/5/13/497, in 3.10 stable, this 
 is 
 the only way to solve the problem and the backport code is a bit more.

 v1 - v2:
  * fix the indent error.
  * rebase on 3.10.79

 Any thoughts?

 Please, wait with the integration. I am testing it with a storm of
 sysrq requests:

 $ while true ; do echo l /proc/sysrq-trigger ; done

 with iptables enabled:

 $ iptables -A INPUT -j LOG --log-prefix incomming packet:

 and storm of pings from other machine:

 $ ping -f patched-host


 The machine somehow freezes. It does not make sense. I am trying to 
 investigate.
 
 OK, it seems that the machine freezes because there are still few
 messages printed in the NMI context, e.g.:
 
 [ 3080.286277] Uhhuh. NMI received for unknown reason 3d on CPU 12.
 [ 3637.939276] Uhhuh. NMI received for unknown reason 2d on CPU 13.
 
 I am not exactly sure why I get them on the test machine. But I get
 such messages from time to time when hammering it by the pings and
 sysrq-l requests.
 
 I modified vprintk_emit() to do raw_spin_trylock(logbuf_lock)
 and do not try to lock console in NMI context. The trylock fails
 from time to time but it does not longer freeze.
 
 I am going to clean up the vprintk_emit() modification and send it for
 review.
 
 Anyway, this patch set seems to work as expected. It heavily reduces
 the risk of NMI/printk-related deadlocks = it is worth having.
 
 Feel free to use the following for the whole patchset (backport):
 
 Reviewed-by: Petr Mladek pmla...@suse.cz
 Tested-by: Petr Mladek pmla...@suse.cz

Hi Greg,

This patch set is the only way to solve the NMI/printk-related deadlock 
problems.
Could you please include them to 3.10 stable?

Although the code a bit more, most of the code is seq_buf infrastructures and
it does not affect other parts of the kernel.


Best Regards
Wang Long


 
 Best Regards,
 Petr
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 16/17] x86/nmi: Perform a safe NMI stack trace on all CPUs

2015-05-19 Thread long.wanglong

On 2015/5/18 22:17, Petr Mladek wrote:
> On Thu 2015-05-14 11:35:03, Wang Long wrote:
>> From: "Steven Rostedt (Red Hat)" 
>>
>> commit a9edc88093287183ac934be44f295f183b2c62dd upstream.
>>
>> When trigger_all_cpu_backtrace() is called on x86, it will trigger an
>> NMI on each CPU and call show_regs(). But this can lead to a hard lock
>> up if the NMI comes in on another printk().
>>
>> In order to avoid this, when the NMI triggers, it switches the printk
>> routine for that CPU to call a NMI safe printk function that records the
>> printk in a per_cpu seq_buf descriptor. After all NMIs have finished
>> recording its data, the seq_bufs are printed in a safe context.
>>
>> Link: http://lkml.kernel.org/p/20140619213952.360076...@goodmis.org
>> Link: http://lkml.kernel.org/r/20141115050605.055232...@goodmis.org
>>
>> Tested-by: Jiri Kosina 
>> Acked-by: Jiri Kosina 
>> Acked-by: Paul E. McKenney 
>> Reviewed-by: Petr Mladek 
>> [wanglong: backport to 3.10 stable
>> - adjust context
>> ]
>> Signed-off-by: Wang Long 
>> Signed-off-by: Steven Rostedt 
>> ---
>>  arch/x86/kernel/apic/hw_nmi.c | 86 
>> +--
>>  1 file changed, 83 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kernel/apic/hw_nmi.c b/arch/x86/kernel/apic/hw_nmi.c
>> index a698d71..1eb5f90 100644
>> --- a/arch/x86/kernel/apic/hw_nmi.c
>> +++ b/arch/x86/kernel/apic/hw_nmi.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #ifdef CONFIG_HARDLOCKUP_DETECTOR
>>  u64 hw_nmi_get_sample_period(int watchdog_thresh)
>> @@ -29,12 +30,33 @@ u64 hw_nmi_get_sample_period(int watchdog_thresh)
>>  #ifdef arch_trigger_all_cpu_backtrace
>>  /* For reliability, we're prepared to waste bits here. */
>>  static DECLARE_BITMAP(backtrace_mask, NR_CPUS) __read_mostly;
>> +static cpumask_var_t printtrace_mask;
>> +
>> +#define NMI_BUF_SIZE   4096
> 
> Please, replace spaces with tabs.
> 
> In fact, the indentation is broken in this whole patch.
> 
> The content looks fine, though.
> 
> Best Regards,
> Petr
> 
Hi Petr,

Thank you for your review. Sorry for the indentation broken.

I will send the patch v2.

Best Regards
Wang Long


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 16/17] x86/nmi: Perform a safe NMI stack trace on all CPUs

2015-05-19 Thread long.wanglong

On 2015/5/18 22:17, Petr Mladek wrote:
 On Thu 2015-05-14 11:35:03, Wang Long wrote:
 From: Steven Rostedt (Red Hat) rost...@goodmis.org

 commit a9edc88093287183ac934be44f295f183b2c62dd upstream.

 When trigger_all_cpu_backtrace() is called on x86, it will trigger an
 NMI on each CPU and call show_regs(). But this can lead to a hard lock
 up if the NMI comes in on another printk().

 In order to avoid this, when the NMI triggers, it switches the printk
 routine for that CPU to call a NMI safe printk function that records the
 printk in a per_cpu seq_buf descriptor. After all NMIs have finished
 recording its data, the seq_bufs are printed in a safe context.

 Link: http://lkml.kernel.org/p/20140619213952.360076...@goodmis.org
 Link: http://lkml.kernel.org/r/20141115050605.055232...@goodmis.org

 Tested-by: Jiri Kosina jkos...@suse.cz
 Acked-by: Jiri Kosina jkos...@suse.cz
 Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
 Reviewed-by: Petr Mladek pmla...@suse.cz
 [wanglong: backport to 3.10 stable
 - adjust context
 ]
 Signed-off-by: Wang Long long.wangl...@huawei.com
 Signed-off-by: Steven Rostedt rost...@goodmis.org
 ---
  arch/x86/kernel/apic/hw_nmi.c | 86 
 +--
  1 file changed, 83 insertions(+), 3 deletions(-)

 diff --git a/arch/x86/kernel/apic/hw_nmi.c b/arch/x86/kernel/apic/hw_nmi.c
 index a698d71..1eb5f90 100644
 --- a/arch/x86/kernel/apic/hw_nmi.c
 +++ b/arch/x86/kernel/apic/hw_nmi.c
 @@ -18,6 +18,7 @@
  #include linux/nmi.h
  #include linux/module.h
  #include linux/delay.h
 +#include linux/seq_buf.h
  
  #ifdef CONFIG_HARDLOCKUP_DETECTOR
  u64 hw_nmi_get_sample_period(int watchdog_thresh)
 @@ -29,12 +30,33 @@ u64 hw_nmi_get_sample_period(int watchdog_thresh)
  #ifdef arch_trigger_all_cpu_backtrace
  /* For reliability, we're prepared to waste bits here. */
  static DECLARE_BITMAP(backtrace_mask, NR_CPUS) __read_mostly;
 +static cpumask_var_t printtrace_mask;
 +
 +#define NMI_BUF_SIZE   4096
 
 Please, replace spaces with tabs.
 
 In fact, the indentation is broken in this whole patch.
 
 The content looks fine, though.
 
 Best Regards,
 Petr
 
Hi Petr,

Thank you for your review. Sorry for the indentation broken.

I will send the patch v2.

Best Regards
Wang Long


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/17][request for stable 3.10 inclusion] x86/nmi: Print all cpu stacks from NMI safely

2015-05-17 Thread long.wanglong

On 2015/5/14 21:55, Steven Rostedt wrote:
> On Thu, 14 May 2015 11:34:47 +
> Wang Long  wrote:
> 
>> The patch 1-13 backport the "seq_buf" infrastructures. in detail, patch 1, 2
>> and 6 only backport "seq_buf" related code.
>>
> 
> Ah, so basically you just backported the seq_buf.c code without
> modifying the trace_seq code. That's a good approach. I don't have much
> time to look at these but I'll try to skim them to see if I find
> anything broken.
> 
> I may pull all of them into a test branch and run my tests to make sure
> they don't break anything else.
> 
> -- Steve
> 
Hi Steve,

Thank you for your review and test. Does your testcases run OK with this
series patches?

Best Regards
Wang Long
> 
>>  arch/x86/kernel/apic/hw_nmi.c |  86 +-
>>  include/linux/percpu.h|   4 +
>>  include/linux/printk.h|   2 +
>>  include/linux/seq_buf.h   | 136 
>>  kernel/printk.c   |  41 +++--
>>  lib/Makefile  |   2 +-
>>  lib/seq_buf.c | 359 
>> ++
>>  7 files changed, 617 insertions(+), 13 deletions(-)
>>  create mode 100644 include/linux/seq_buf.h
>>  create mode 100644 lib/seq_buf.c
>>
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/17][request for stable 3.10 inclusion] x86/nmi: Print all cpu stacks from NMI safely

2015-05-17 Thread long.wanglong

On 2015/5/14 21:55, Steven Rostedt wrote:
 On Thu, 14 May 2015 11:34:47 +
 Wang Long long.wangl...@huawei.com wrote:
 
 The patch 1-13 backport the seq_buf infrastructures. in detail, patch 1, 2
 and 6 only backport seq_buf related code.

 
 Ah, so basically you just backported the seq_buf.c code without
 modifying the trace_seq code. That's a good approach. I don't have much
 time to look at these but I'll try to skim them to see if I find
 anything broken.
 
 I may pull all of them into a test branch and run my tests to make sure
 they don't break anything else.
 
 -- Steve
 
Hi Steve,

Thank you for your review and test. Does your testcases run OK with this
series patches?

Best Regards
Wang Long
 
  arch/x86/kernel/apic/hw_nmi.c |  86 +-
  include/linux/percpu.h|   4 +
  include/linux/printk.h|   2 +
  include/linux/seq_buf.h   | 136 
  kernel/printk.c   |  41 +++--
  lib/Makefile  |   2 +-
  lib/seq_buf.c | 359 
 ++
  7 files changed, 617 insertions(+), 13 deletions(-)
  create mode 100644 include/linux/seq_buf.h
  create mode 100644 lib/seq_buf.c

 
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] how to perform a safe NMI stack trace on all CPUs on x86?

On 2015/5/13 22:26, Jiri Kosina wrote:
> On Wed, 13 May 2015, 王龙 wrote:
> 
>> Hi all,
>>
>> In kernel before 3.19, when trigger_all_cpu_backtrace() is called on x86, 
>> it will trigger an NMI on each CPU and call show_regs(). But this can lead
>> to a hard lock up if the NMI comes in on another printk().
>>
>> The commit a9edc88093287183ac934be44f295f183b2c62dd (x86/nmi: Perform a safe 
>> NMI stack trace on all CPUs) fix this problem on kernel mainline. when the 
>> NMI 
>> triggers, it switches the printk routine for that CPU to call a NMI safe 
>> printk 
>> function that records the printk in a per_cpu seq_buf descriptor. After all 
>> NMIs have finished recording its data, the seq_bufs are printed in a safe 
>> context. But how do we fix this problem in older version of kernel(eg, 3.10 
>> stable)? 
>> The 3.10 stable has no "switch printk routine" and "seq_buf" infrastructures.
>>
>> Could anyone give me some ideas?
> 
> Either you backport seq_buf-based aproach to the older kernel, or, if you 
> are working on 3.4 kernel or earlier (basically any kernel preceeding the 
> printk() revamp that happened in 7ff9554bb57 and after), you can use 
> slightly simpler aproach.
> 
> It's an aproach we used initially when finding out the issue for the first 
> time, and it is proven to work as well (but it's not applicable after Kay 
> added all the complexity to printk()).
> 
> You can see it in our SLE11 kernel tree, available on
>   
>   
> http://kernel.suse.com/cgit/kernel/commit/?h=SLE11-SP4=8d62ae68ff61d77ae3c4899f05dbd9c9742b14c9
> 
> for example.
> 
> It's up to you to judget which is the least painful way :)
> 

Hi Jiri Kosina,

For 3.10 stable, the only way to solve this problem is backport seq_buf-based 
aproach.

I will backport necessary patches to 3.10 stable. Welcome you to review my 
backport patches.

Best Regards
Wang Long




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] how to perform a safe NMI stack trace on all CPUs on x86?

On 2015/5/13 22:22, Steven Rostedt wrote:
> On Wed, 13 May 2015 22:14:54 +0800
> "王龙"  wrote:
> 
> 
>> context. But how do we fix this problem in older version of kernel(eg, 3.10 
>> stable)? 
>> The 3.10 stable has no "switch printk routine" and "seq_buf" infrastructures.
>>
>> Could anyone give me some ideas?
>>
> 
> Backport the necessary patches.
> 
> -- Steve
> 
Hi Steve,

Thank you for your reply, I will backport necessary patches to 3.10 stable.
Welcome you to review my backport patches.

Best Regards
Wang Long
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] how to perform a safe NMI stack trace on all CPUs on x86?

On 2015/5/13 22:26, Jiri Kosina wrote:
On Wed, 13 May 2015, 王龙 wrote:

Hi all,

In kernel before 3.19, when trigger_all_cpu_backtrace() is called on x86,
it will trigger an NMI on each CPU and call show_regs(). But this can lead
to a hard lock up if the NMI comes in on another printk().

The commit a9edc88093287183ac934be44f295f183b2c62dd (x86/nmi: Perform a safe
NMI stack trace on all CPUs) fix this problem on kernel mainline. when the
NMI
triggers, it switches the printk routine for that CPU to call a NMI safe
printk
function that records the printk in a per_cpu seq_buf descriptor. After all
NMIs have finished recording its data, the seq_bufs are printed in a safe
context. But how do we fix this problem in older version of kernel(eg, 3.10
stable)?
The 3.10 stable has no switch printk routine and seq_buf infrastructures.

Could anyone give me some ideas?

Either you backport seq_buf-based aproach to the older kernel, or, if you
are working on 3.4 kernel or earlier (basically any kernel preceeding the
printk() revamp that happened in 7ff9554bb57 and after), you can use
slightly simpler aproach.

It's an aproach we used initially when finding out the issue for the first
time, and it is proven to work as well (but it's not applicable after Kay
added all the complexity to printk()).

You can see it in our SLE11 kernel tree, available on

http://kernel.suse.com/cgit/kernel/commit/?h=SLE11-SP4id=8d62ae68ff61d77ae3c4899f05dbd9c9742b14c9

for example.

It's up to you to judget which is the least painful way :)

Hi Jiri Kosina,

For 3.10 stable, the only way to solve this problem is backport seq_buf-based
aproach.

I will backport necessary patches to 3.10 stable. Welcome you to review my
backport patches.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] how to perform a safe NMI stack trace on all CPUs on x86?

On 2015/5/13 22:22, Steven Rostedt wrote:
 On Wed, 13 May 2015 22:14:54 +0800
 王龙 wangl...@laoqinren.net wrote:
 
 
 context. But how do we fix this problem in older version of kernel(eg, 3.10 
 stable)? 
 The 3.10 stable has no switch printk routine and seq_buf infrastructures.

 Could anyone give me some ideas?

 
 Backport the necessary patches.
 
 -- Steve
 
Hi Steve,

Thank you for your reply, I will backport necessary patches to 3.10 stable.
Welcome you to review my backport patches.

Best Regards
Wang Long
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] kernel random segmentation fault?

2015-05-06 Thread long.wanglong

On 2015/5/6 16:20, Hillf Danton wrote:
>>
>> Hi all:
>>
>> I meet a kernel problem about the random segmentation fault(x86_64). In my 
>> testcase, the size of local variables exceeds 20MB.
>> when run the testcase, it will cause segmentation fault(because the default 
>> stack size limit is 8192KB).
>> when I increase the stack size limit to 1024000KB(ulimit -s 1024000), the 
>> testcase will pass.
>>
>> But when I run the testcase 100 times, it will cause random segmentation 
>> fault.
>>
>> Maybe the commit fee7e49d45149fba60156f5b59014f764d3e3728  "mm: propagate 
>> error from stack expansion even for guard page"
>> cause this problems, when I revert it, the testcase will not cause random 
>> segmentation fault problem.
>>
>> Can anyone give some ideas about this problem?
>>
>> Best Regards
>> Wang Long
>>
>>  Test Environment #
>>
>> # uname -a
>> Linux ivybridge 4.1.0-rc2+ #3 SMP PREEMPT Wed May 6 10:46:57 CST 2015 x86_64 
>> x86_64 x86_64 GNU/Linux
>>
>>
>>   The Testcase 
>>
>> #include 
>> #include 
>> #include 
>>
>> #define KB *1024
>> #define MB *(1024*1024)
>> #define GB *(1024*1024*1024)
>>
>> int main(int argc, char** argv)
>> {
>> int ret;
>> struct rlimit rlim;
>>
>> rlim.rlim_cur=20 MB;
>> rlim.rlim_max=20 MB;
> 
> Can you please get rlimit before setting it?
> And try again without reverting fee7e49d45?
>

Hi,Hillf Danton

After add getrlimit function before setting it. the testcase will not cause
random segmentation fault problem.

Could you please explain why? Are there any special considerations when we
use setrlimit and getrlimit functions?

Best Regards
Wang Long

>> ret = setrlimit(RLIMIT_AS, );
>> if ( 0 > ret)
>> {
>> perror("setrlimit failed");
>> exit(1);
>> }
>>
>> printf("setrlimit success\n");
>>
>> char tmp[20 MB];
>> int i = 0;
>>
>> for (i = 0; i < 20 MB; i++)
>> {
>> tmp[i]=1;
>> }
>>
>> printf("test success\n");
>> exit(1);
>> }
>>
> 
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] kernel random segmentation fault?

2015-05-06 Thread long.wanglong

On 2015/5/6 16:20, Hillf Danton wrote:

 Hi all:

 I meet a kernel problem about the random segmentation fault(x86_64). In my 
 testcase, the size of local variables exceeds 20MB.
 when run the testcase, it will cause segmentation fault(because the default 
 stack size limit is 8192KB).
 when I increase the stack size limit to 1024000KB(ulimit -s 1024000), the 
 testcase will pass.

 But when I run the testcase 100 times, it will cause random segmentation 
 fault.

 Maybe the commit fee7e49d45149fba60156f5b59014f764d3e3728  mm: propagate 
 error from stack expansion even for guard page
 cause this problems, when I revert it, the testcase will not cause random 
 segmentation fault problem.

 Can anyone give some ideas about this problem?

 Best Regards
 Wang Long

  Test Environment #

 # uname -a
 Linux ivybridge 4.1.0-rc2+ #3 SMP PREEMPT Wed May 6 10:46:57 CST 2015 x86_64 
 x86_64 x86_64 GNU/Linux


   The Testcase 

 #include stdio.h
 #include stdlib.h
 #include sys/resource.h

 #define KB *1024
 #define MB *(1024*1024)
 #define GB *(1024*1024*1024)

 int main(int argc, char** argv)
 {
 int ret;
 struct rlimit rlim;

 rlim.rlim_cur=20 MB;
 rlim.rlim_max=20 MB;
 
 Can you please get rlimit before setting it?
 And try again without reverting fee7e49d45?


Hi,Hillf Danton

After add getrlimit function before setting it. the testcase will not cause
random segmentation fault problem.

Could you please explain why? Are there any special considerations when we
use setrlimit and getrlimit functions?

Best Regards
Wang Long

 ret = setrlimit(RLIMIT_AS, rlim);
 if ( 0  ret)
 {
 perror(setrlimit failed);
 exit(1);
 }

 printf(setrlimit success\n);

 char tmp[20 MB];
 int i = 0;

 for (i = 0; i  20 MB; i++)
 {
 tmp[i]=1;
 }

 printf(test success\n);
 exit(1);
 }

 
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] kernel random segmentation fault?

2015-05-05 Thread long.wanglong

Hi all:

I meet a kernel problem about the random segmentation fault(x86_64). In my 
testcase, the size of local variables exceeds 20MB.
when run the testcase, it will cause segmentation fault(because the default 
stack size limit is 8192KB).
when I increase the stack size limit to 1024000KB(ulimit -s 1024000), the 
testcase will pass.

But when I run the testcase 100 times, it will cause random segmentation fault.

Maybe the commit fee7e49d45149fba60156f5b59014f764d3e3728  "mm: propagate error 
from stack expansion even for guard page"
cause this problems, when I revert it, the testcase will not cause random 
segmentation fault problem.

Can anyone give some ideas about this problem?

Best Regards
Wang Long

 Test Environment #

# uname -a
Linux ivybridge 4.1.0-rc2+ #3 SMP PREEMPT Wed May 6 10:46:57 CST 2015 x86_64 
x86_64 x86_64 GNU/Linux


  The Testcase 

#include 
#include 
#include 

#define KB *1024
#define MB *(1024*1024)
#define GB *(1024*1024*1024)

int main(int argc, char** argv)
{
int ret;
struct rlimit rlim;

rlim.rlim_cur=20 MB;
rlim.rlim_max=20 MB;
ret = setrlimit(RLIMIT_AS, );
if ( 0 > ret)
{
perror("setrlimit failed");
exit(1);
}

printf("setrlimit success\n");

char tmp[20 MB];
int i = 0;

for (i = 0; i < 20 MB; i++)
{
tmp[i]=1;
}

printf("test success\n");
exit(1);
}

# My config


-- 
1.8.3.4


.



#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.1.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=64

[RFC] kernel random segmentation fault?

2015-05-05 Thread long.wanglong

Hi all:

I meet a kernel problem about the random segmentation fault(x86_64). In my 
testcase, the size of local variables exceeds 20MB.
when run the testcase, it will cause segmentation fault(because the default 
stack size limit is 8192KB).
when I increase the stack size limit to 1024000KB(ulimit -s 1024000), the 
testcase will pass.

But when I run the testcase 100 times, it will cause random segmentation fault.

Maybe the commit fee7e49d45149fba60156f5b59014f764d3e3728  mm: propagate error 
from stack expansion even for guard page
cause this problems, when I revert it, the testcase will not cause random 
segmentation fault problem.

Can anyone give some ideas about this problem?

Best Regards
Wang Long

 Test Environment #

# uname -a
Linux ivybridge 4.1.0-rc2+ #3 SMP PREEMPT Wed May 6 10:46:57 CST 2015 x86_64 
x86_64 x86_64 GNU/Linux


  The Testcase 

#include stdio.h
#include stdlib.h
#include sys/resource.h

#define KB *1024
#define MB *(1024*1024)
#define GB *(1024*1024*1024)

int main(int argc, char** argv)
{
int ret;
struct rlimit rlim;

rlim.rlim_cur=20 MB;
rlim.rlim_max=20 MB;
ret = setrlimit(RLIMIT_AS, rlim);
if ( 0  ret)
{
perror(setrlimit failed);
exit(1);
}

printf(setrlimit success\n);

char tmp[20 MB];
int i = 0;

for (i = 0; i  20 MB; i++)
{
tmp[i]=1;
}

printf(test success\n);
exit(1);
}

# My config


-- 
1.8.3.4


.



#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.1.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=64

Re: [PATCH] Documentation: cpu-freq: delete duplicate description of sysfs interface 'scaling_driver'

On 2015/5/5 5:27, Rafael J. Wysocki wrote:
> On Monday, May 04, 2015 09:16:58 AM Wang Long wrote:
>> The file 'Documentation/cpu-freq/user-guide.txt' has duplicate
>> description of sysfs interface 'scaling_driver'.
>>
>> [first]
>> scaling_driver :this file shows what cpufreq driver is
>>  used to set the frequency on this CPU
>>
>> [second]
>> scaling_driver :Hardware driver for cpufreq.
>>
>> Although this does not affect anything, I think we should only have
>> one. so delete the second one because the first one is described in
>> more detail.
>>
>> Signed-off-by: Wang Long 
> 
> Can you please CC this one (and any future cpufreq patches) to
> linux...@vger.kernel.org too?  It'll be easier to track it using Patchwork
> then.
> 
> 

OK, I will relay to this mail with CC the patch to linux...@vger.kernel.org.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/pstore: update the backend parameter in pstore module

On 2015/3/26 23:48, Mark Salyzyn wrote:
> On 03/26/2015 03:08 AM, Wang Long wrote:
>> This patch update the module parameter backend, so it is visible
>> through /sys/module/pstore/parameters/backend.
>>
>> For example:
>> if pstore backend is ramoops, with this patch:
>> # cat /sys/module/pstore/parameters/backend
>> ramoops
>> and without this patch:
>> # cat /sys/module/pstore/parameters/backend
>> (null)
>>
>> Signed-off-by: Wang Long 
> Ack
> 
> Sincerely -- Mark Salyzyn
> 
> 
Hi Tony Luck,

Could you please help to commit this patch?

Thank you.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] fs/pstore: Optimization function ramoops_init_przs

On 2015/3/19 4:11, Kees Cook wrote:
> On Tue, Mar 17, 2015 at 6:41 PM, Wang Long  wrote:
>> The value of cxt->record_size does not change in the loop,
>> so this patch optimize the assign statement by dropping
>> sz entirely and using cxt->record_size in its place.
>>
>> Signed-off-by: Wang Long 
> 
> Thanks!
> 
> Acked-by: Kees Cook 
> 
> -Kees
> 
>> ---
>>  fs/pstore/ram.c | 8 +++-
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
>> index 44a549b..f29373d 100644
>> --- a/fs/pstore/ram.c
>> +++ b/fs/pstore/ram.c
>> @@ -394,18 +394,16 @@ static int ramoops_init_przs(struct device *dev, 
>> struct ramoops_context *cxt,
>> }
>>
>> for (i = 0; i < cxt->max_dump_cnt; i++) {
>> -   size_t sz = cxt->record_size;
>> -
>> -   cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
>> +   cxt->przs[i] = persistent_ram_new(*paddr, cxt->record_size, 
>> 0,
>>   >ecc_info,
>>   cxt->memtype);
>> if (IS_ERR(cxt->przs[i])) {
>> err = PTR_ERR(cxt->przs[i]);
>> dev_err(dev, "failed to request mem region 
>> (0x%zx@0x%llx): %d\n",
>> -   sz, (unsigned long long)*paddr, err);
>> +   cxt->record_size, (unsigned long 
>> long)*paddr, err);
>> goto fail_prz;
>> }
>> -   *paddr += sz;
>> +   *paddr += cxt->record_size;
>> }
>>
>> return 0;
>> --
>> 1.8.3.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 

Hi Tony Luck,

Could you please help to commit this patch?

Thank you.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ramoops: make it possible to change mem_type param.

On 2015/4/3 1:10, marco wrote:
>> On 03/30/2015 06:33 PM, Wang Long wrote:
>>>   dummy_data->mem_size = mem_size;
>>>   dummy_data->mem_address = mem_address;
>>> -dummy_data->mem_type = 0;
>>> +dummy_data->mem_type = mem_type;
>>>   dummy_data->record_size = record_size;
>>>   dummy_data->console_size = ramoops_console_size;
>>>   dummy_data->ftrace_size = ramoops_ftrace_size;
>> Ack
> 
> Acked-by: Marco Stornelli 
> 
> .
> 

Hi Tony Luck,

Could you please help to commit this patch?

Thank you.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ramoops: make it possible to change mem_type param.

On 2015/4/3 1:10, marco wrote:
 On 03/30/2015 06:33 PM, Wang Long wrote:
   dummy_data-mem_size = mem_size;
   dummy_data-mem_address = mem_address;
 -dummy_data-mem_type = 0;
 +dummy_data-mem_type = mem_type;
   dummy_data-record_size = record_size;
   dummy_data-console_size = ramoops_console_size;
   dummy_data-ftrace_size = ramoops_ftrace_size;
 Ack
 
 Acked-by: Marco Stornelli marco.storne...@gmail.com
 
 .
 

Hi Tony Luck,

Could you please help to commit this patch?

Thank you.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] fs/pstore: Optimization function ramoops_init_przs

On 2015/3/19 4:11, Kees Cook wrote:
 On Tue, Mar 17, 2015 at 6:41 PM, Wang Long long.wangl...@huawei.com wrote:
 The value of cxt-record_size does not change in the loop,
 so this patch optimize the assign statement by dropping
 sz entirely and using cxt-record_size in its place.

 Signed-off-by: Wang Long long.wangl...@huawei.com
 
 Thanks!
 
 Acked-by: Kees Cook keesc...@chromium.org
 
 -Kees
 
 ---
  fs/pstore/ram.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

 diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
 index 44a549b..f29373d 100644
 --- a/fs/pstore/ram.c
 +++ b/fs/pstore/ram.c
 @@ -394,18 +394,16 @@ static int ramoops_init_przs(struct device *dev, 
 struct ramoops_context *cxt,
 }

 for (i = 0; i  cxt-max_dump_cnt; i++) {
 -   size_t sz = cxt-record_size;
 -
 -   cxt-przs[i] = persistent_ram_new(*paddr, sz, 0,
 +   cxt-przs[i] = persistent_ram_new(*paddr, cxt-record_size, 
 0,
   cxt-ecc_info,
   cxt-memtype);
 if (IS_ERR(cxt-przs[i])) {
 err = PTR_ERR(cxt-przs[i]);
 dev_err(dev, failed to request mem region 
 (0x%zx@0x%llx): %d\n,
 -   sz, (unsigned long long)*paddr, err);
 +   cxt-record_size, (unsigned long 
 long)*paddr, err);
 goto fail_prz;
 }
 -   *paddr += sz;
 +   *paddr += cxt-record_size;
 }

 return 0;
 --
 1.8.3.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Hi Tony Luck,

Could you please help to commit this patch?

Thank you.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/pstore: update the backend parameter in pstore module

On 2015/3/26 23:48, Mark Salyzyn wrote:
 On 03/26/2015 03:08 AM, Wang Long wrote:
 This patch update the module parameter backend, so it is visible
 through /sys/module/pstore/parameters/backend.

 For example:
 if pstore backend is ramoops, with this patch:
 # cat /sys/module/pstore/parameters/backend
 ramoops
 and without this patch:
 # cat /sys/module/pstore/parameters/backend
 (null)

 Signed-off-by: Wang Long long.wangl...@huawei.com
 Ack
 
 Sincerely -- Mark Salyzyn
 
 
Hi Tony Luck,

Could you please help to commit this patch?

Thank you.

Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: cpu-freq: delete duplicate description of sysfs interface 'scaling_driver'

On 2015/5/5 5:27, Rafael J. Wysocki wrote:
 On Monday, May 04, 2015 09:16:58 AM Wang Long wrote:
 The file 'Documentation/cpu-freq/user-guide.txt' has duplicate
 description of sysfs interface 'scaling_driver'.

 [first]
 scaling_driver :this file shows what cpufreq driver is
  used to set the frequency on this CPU

 [second]
 scaling_driver :Hardware driver for cpufreq.

 Although this does not affect anything, I think we should only have
 one. so delete the second one because the first one is described in
 more detail.

 Signed-off-by: Wang Long long.wangl...@huawei.com
 
 Can you please CC this one (and any future cpufreq patches) to
 linux...@vger.kernel.org too?  It'll be easier to track it using Patchwork
 then.
 
 

OK, I will relay to this mail with CC the patch to linux...@vger.kernel.org.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ramoops: make it possible to change mem_type param.

2015-03-30 Thread long.wanglong

On 2015/3/31 0:31, Tony Lindgren wrote:
> * Wang Long  [150327 02:43]:
>> If we set ramoops.mem_type=1 in command line, the current
>> code can not change mem_type to 1, because it is assigned
>> to 0 in function ramoops_register_dummy.
>>
>> This patch make it possible to change mem_type parameter
>> in command line.
>>
>> Signed-off-by: Wang Long 
>>
>> ---
>>  fs/pstore/ram.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
>> index 44a549b..65e0532 100644
>> --- a/fs/pstore/ram.c
>> +++ b/fs/pstore/ram.c
>> @@ -65,7 +65,7 @@ module_param(mem_size, ulong, 0400);
>>  MODULE_PARM_DESC(mem_size,
>>  "size of reserved RAM used to store oops/panic logs");
>>  
>> -static unsigned int mem_type;
>> +static unsigned int mem_type = 0;
>>  module_param(mem_type, uint, 0600);
>>  MODULE_PARM_DESC(mem_type,
>>  "set to 1 to try to use unbuffered memory (default 0)");
> 
> The BSS gets cleared during init so no need to initialize the mem_type
> separately here and you can drop the change above AFAIK.
> 
OK, thanks.
i will drop this change.

>> @@ -608,7 +608,7 @@ static void ramoops_register_dummy(void)
>>  
>>  dummy_data->mem_size = mem_size;
>>  dummy_data->mem_address = mem_address;
>> -dummy_data->mem_type = 0;
>> +dummy_data->mem_type = mem_type;
>>  dummy_data->record_size = record_size;
>>  dummy_data->console_size = ramoops_console_size;
>>  dummy_data->ftrace_size = ramoops_ftrace_size;
> 
> For this change sounds like a bug. Sorry I was not able to test
> that with the hardware I have here. Good thing you have been able
> to verify it with your hardware. If you drop the first part and
> repost, please also feel free to add:
> 
> Acked-by: Tony Lindgren 
> 
> .
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ramoops: make it possible to change mem_type param.

2015-03-30 Thread long.wanglong

On 2015/3/31 0:31, Tony Lindgren wrote:
 * Wang Long long.wangl...@huawei.com [150327 02:43]:
 If we set ramoops.mem_type=1 in command line, the current
 code can not change mem_type to 1, because it is assigned
 to 0 in function ramoops_register_dummy.

 This patch make it possible to change mem_type parameter
 in command line.

 Signed-off-by: Wang Long long.wangl...@huawei.com

 ---
  fs/pstore/ram.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
 index 44a549b..65e0532 100644
 --- a/fs/pstore/ram.c
 +++ b/fs/pstore/ram.c
 @@ -65,7 +65,7 @@ module_param(mem_size, ulong, 0400);
  MODULE_PARM_DESC(mem_size,
  size of reserved RAM used to store oops/panic logs);
  
 -static unsigned int mem_type;
 +static unsigned int mem_type = 0;
  module_param(mem_type, uint, 0600);
  MODULE_PARM_DESC(mem_type,
  set to 1 to try to use unbuffered memory (default 0));
 
 The BSS gets cleared during init so no need to initialize the mem_type
 separately here and you can drop the change above AFAIK.
 
OK, thanks.
i will drop this change.

 @@ -608,7 +608,7 @@ static void ramoops_register_dummy(void)
  
  dummy_data-mem_size = mem_size;
  dummy_data-mem_address = mem_address;
 -dummy_data-mem_type = 0;
 +dummy_data-mem_type = mem_type;
  dummy_data-record_size = record_size;
  dummy_data-console_size = ramoops_console_size;
  dummy_data-ftrace_size = ramoops_ftrace_size;
 
 For this change sounds like a bug. Sorry I was not able to test
 that with the hardware I have here. Good thing you have been able
 to verify it with your hardware. If you drop the first part and
 repost, please also feel free to add:
 
 Acked-by: Tony Lindgren t...@atomide.com
 
 .
 



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/pstore: Optimization function ramoops_init_przs

2015-03-17 Thread long.wanglong

On 2015/3/18 1:39, Kees Cook wrote:
> On Tue, Mar 17, 2015 at 2:31 AM, Wang Long  wrote:
>> The value of cxt->record_size does not change in the loop,
>> so this patch optimize the assign statement by moving
>> it to outer.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  fs/pstore/ram.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
>> index 44a549b..2105a16 100644
>> --- a/fs/pstore/ram.c
>> +++ b/fs/pstore/ram.c
>> @@ -373,6 +373,7 @@ static int ramoops_init_przs(struct device *dev, struct 
>> ramoops_context *cxt,
>>  {
>> int err = -ENOMEM;
>> int i;
>> +   size_t sz;
>>
>> if (!cxt->record_size)
>> return 0;
>> @@ -393,9 +394,8 @@ static int ramoops_init_przs(struct device *dev, struct 
>> ramoops_context *cxt,
>> goto fail_prz;
>> }
>>
>> +   sz = cxt->record_size;
>> for (i = 0; i < cxt->max_dump_cnt; i++) {
>> -   size_t sz = cxt->record_size;
>> -
>> cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
>>   >ecc_info,
>>   cxt->memtype);
>> --
>> 1.8.3.4
>>
> 
> Actually, can't we drop sz entirely and just use cxt->record_size in its 
> place?
> 
> -Kees
> 
I agree with you.
drop sz entirely and  use cxt->record_size in its place can improve readability.

I will send another patch.

Best Regards

Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/pstore: Optimization function ramoops_init_przs

2015-03-17 Thread long.wanglong

On 2015/3/18 1:39, Kees Cook wrote:
 On Tue, Mar 17, 2015 at 2:31 AM, Wang Long long.wangl...@huawei.com wrote:
 The value of cxt-record_size does not change in the loop,
 so this patch optimize the assign statement by moving
 it to outer.

 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  fs/pstore/ram.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
 index 44a549b..2105a16 100644
 --- a/fs/pstore/ram.c
 +++ b/fs/pstore/ram.c
 @@ -373,6 +373,7 @@ static int ramoops_init_przs(struct device *dev, struct 
 ramoops_context *cxt,
  {
 int err = -ENOMEM;
 int i;
 +   size_t sz;

 if (!cxt-record_size)
 return 0;
 @@ -393,9 +394,8 @@ static int ramoops_init_przs(struct device *dev, struct 
 ramoops_context *cxt,
 goto fail_prz;
 }

 +   sz = cxt-record_size;
 for (i = 0; i  cxt-max_dump_cnt; i++) {
 -   size_t sz = cxt-record_size;
 -
 cxt-przs[i] = persistent_ram_new(*paddr, sz, 0,
   cxt-ecc_info,
   cxt-memtype);
 --
 1.8.3.4

 
 Actually, can't we drop sz entirely and just use cxt-record_size in its 
 place?
 
 -Kees
 
I agree with you.
drop sz entirely and  use cxt-record_size in its place can improve readability.

I will send another patch.

Best Regards

Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update the CONFIG_DEBUG_PAGEALLOC description

On 2015/3/2 15:28, Wang Long wrote:

cc: vegard.nos...@gmail.com

> The CONFIG_DEBUG_PAGEALLOC option now is located under "Kernel
> hacking" / "Memory Debugging" / "Debug page memory allocations".
> so we should update the description in kmemcheck.txt.
> 
> Signed-off-by: Wang Long 
> ---
>  Documentation/kmemcheck.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt
> index a41bdeb..80aae85 100644
> --- a/Documentation/kmemcheck.txt
> +++ b/Documentation/kmemcheck.txt
> @@ -82,8 +82,8 @@ menu to even appear in "menuconfig". These are:
>  
>o CONFIG_DEBUG_PAGEALLOC=n
>  
> - This option is located under "Kernel hacking" / "Debug page memory
> - allocations".
> + This option is located under "Kernel hacking" / "Memory Debugging"
> +  / "Debug page memory allocations".
>  
>  In addition, I highly recommend turning on CONFIG_DEBUG_INFO=y. This is also
>  located under "Kernel hacking". With this, you will be able to get line 
> number
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] Documentation: update the of_selftest.txt

On 2015/3/10 23:16, Gaurav Minocha wrote:
> Hi Rob,
> 
> On Mar 10, 2015 7:51 AM, "Rob Herring"  > wrote:
>>
>> On Tue, Mar 10, 2015 at 9:44 AM, Rob Herring > > wrote:
>> > On Sun, Mar 8, 2015 at 9:35 PM, Wang Long > > > wrote:
>> >> Since the directory "drivers/of/testcase-data" is renamed
>> >> to "drivers/of/unittest-data". so we should update the path
>> >> in the of_selftest.txt.
>>
>> [...]
>>
>> >> -Before executing OF selftest, it is required to attach the test data to
>> >> +Before executing OF unittest, it is required to attach the test data to
>> >>  machine's device tree (if present). So, when selftest_data_add() is 
>> >> called,
>> >
>> > This one too.
>>
>> Or not. The functions are all still "selftest". Not sure why Grant
>> left all those...
> 
> I will send a patch to replace the selftest with unitest also will update the 
> document if required..
> 
Hi Gaurav, Rob

I have done the work. before replacing the selftest with unittest, i will fix 
some error in OF unittest.
Please review my patch, and give me some advices.

Thanks.

Best Regards
Wang Long

>>
>> Rob
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] Documentation: update the of_selftest.txt

On 2015/3/10 23:16, Gaurav Minocha wrote:
 Hi Rob,
 
 On Mar 10, 2015 7:51 AM, Rob Herring robherri...@gmail.com 
 mailto:robherri...@gmail.com wrote:

 On Tue, Mar 10, 2015 at 9:44 AM, Rob Herring robherri...@gmail.com 
 mailto:robherri...@gmail.com wrote:
  On Sun, Mar 8, 2015 at 9:35 PM, Wang Long long.wangl...@huawei.com 
  mailto:long.wangl...@huawei.com wrote:
  Since the directory drivers/of/testcase-data is renamed
  to drivers/of/unittest-data. so we should update the path
  in the of_selftest.txt.

 [...]

  -Before executing OF selftest, it is required to attach the test data to
  +Before executing OF unittest, it is required to attach the test data to
   machine's device tree (if present). So, when selftest_data_add() is 
  called,
 
  This one too.

 Or not. The functions are all still selftest. Not sure why Grant
 left all those...
 
 I will send a patch to replace the selftest with unitest also will update the 
 document if required..
 
Hi Gaurav, Rob

I have done the work. before replacing the selftest with unittest, i will fix 
some error in OF unittest.
Please review my patch, and give me some advices.

Thanks.

Best Regards
Wang Long


 Rob
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update the CONFIG_DEBUG_PAGEALLOC description

On 2015/3/2 15:28, Wang Long wrote:

cc: vegard.nos...@gmail.com

 The CONFIG_DEBUG_PAGEALLOC option now is located under Kernel
 hacking / Memory Debugging / Debug page memory allocations.
 so we should update the description in kmemcheck.txt.
 
 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  Documentation/kmemcheck.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt
 index a41bdeb..80aae85 100644
 --- a/Documentation/kmemcheck.txt
 +++ b/Documentation/kmemcheck.txt
 @@ -82,8 +82,8 @@ menu to even appear in menuconfig. These are:
  
o CONFIG_DEBUG_PAGEALLOC=n
  
 - This option is located under Kernel hacking / Debug page memory
 - allocations.
 + This option is located under Kernel hacking / Memory Debugging
 +  / Debug page memory allocations.
  
  In addition, I highly recommend turning on CONFIG_DEBUG_INFO=y. This is also
  located under Kernel hacking. With this, you will be able to get line 
 number
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/pstore/ram.c: Fix the ramoops module parameters update

On 2015/3/9 15:39, Wang Long wrote:
cc: marco.storne...@gmail.com
cc: anton.voront...@linaro.org
cc: saly...@android.com
cc: ser...@chromium.org

> In the function ramoops_probe, the console_size, pmsg_size,
> ftrace_size may be update because the value is not the power
> of two. We should update the module parameter variables
> as well so they are visible through /sys/module/ramoops/parameters
> correctly.
> 
> Signed-off-by: Wang Long 
> ---
>  fs/pstore/ram.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 5df325e..1aaa8dc 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -559,6 +559,9 @@ pr_info("[%s] pstore_register", __func__);
>   mem_address = pdata->mem_address;
>   record_size = pdata->record_size;
>   dump_oops = pdata->dump_oops;
> + ramoops_console_size = pdata->console_size;
> + ramoops_pmsg_size = pdata->pmsg_size;
> + ramoops_ftrace_size = pdata->ftrace_size;
>  
>   pr_info("attached 0x%lx@0x%llx, ecc: %d/%d\n",
>   cxt->size, (unsigned long long)cxt->phys_addr,
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

On 2015/3/7 11:01, Tim Kryger wrote:
> You only hit the silicon bug if you bombard the uart with characters
> and simultaneously request a baud rate or framing change.
> 
> I'm not sure why you would do either to the uart console.  Is it
> possible your host machine is doing something weird?
> 
> If you have the leverage, remind the SoC vendor to upgrade the serial
> block.  Synopsys fixed this a long time ago.
> 
> -Tim

Hi, Tim

thanks for you reply. if we bombard the uart with characters and simultaneously
request a baud rate change, we hit the silicon bug.

Our scenario is to do stability testing（at the system booting, we bombard the 
uart
with characters）, With this version(v3.0.6) Synopsys Serial,  the expect are
print out the message(Couldn't set LCR to ) and the kernel will not hung.

Maybe the next release of the board we will upgrade the serial block to the new 
version.
but the issue is that how we circumvent this problem in kernel?

do you have any ideas? thanks.

Best Regards
Wang Long


> 
> On Fri, Mar 6, 2015 at 8:50 AM, Peter Hurley  wrote:
>> Hi Zhang,
>>
>> On 03/06/2015 04:11 AM, Zhang Zhen wrote:
>>> Hi,
>>>
>>>   I'm testing 4.0-rc1 kernel on my board with 8250 Designware UART.(ARM 
>>> Cortex-a15 single core).
>>>
>>>   I found if serial is busy and writes to the LCR failed after tried 
>>> 1000 times.
>>>   The kernel will hung up.
>>>
>>>   The system boot success after changed from:
>>>
>>>  95 static void dw8250_serial_out(struct uart_port *p, int offset, int 
>>> value)
>>>  96 {
>>>  97 struct dw8250_data *d = p->private_data;
>>>  98
>>> ...
>>> ...
>>> 112 writeb(value, p->membase + (UART_LCR << 
>>> p->regshift));
>>> 113 }
>>> 114 dev_err(p->dev, "Couldn't set LCR to %d\n", value);
>>> 115 }
>>> 116 }
>>>
>>>   to:
>>>
>>>  95 static void dw8250_serial_out(struct uart_port *p, int offset, int 
>>> value)
>>>  96 {
>>>  97 struct dw8250_data *d = p->private_data;
>>>  98
>>> ...
>>> ...
>>> 112 writeb(value, p->membase + (UART_LCR << 
>>> p->regshift));
>>> 113 }
>>> 114 dev_info(p->dev, "Couldn't set LCR to %d\n", value);
>>> //changed here
>>> 115 }
>>> 116 }
>>>
>>>   The reason is serial8250_console_write can't get port->lock because 
>>> serial8250_do_set_termios has
>>>   got port->lock.
>>>   So i think here we should change from dev_err to dev_info ?
>>
>> That's not really going to help because this will still hang if the
>> console_loglevel is set to < KERN_INFO.
>>
>>>   Any suggestions are welcome.
>>
>> Check that the port is not the uart_console() before logging the error,
>> like;
>>
>> if (!uart_console(p))
>> dev_err(p->dev, "Couldn't .");
>>
>> Use a global flag to note the error and check it from other contexts.
>> Plus, find out why you can't write LCR there.
>>
>> Also, consider re-designing how the 8250_dw driver implements that
>> "feature".
>>
>> Regards,
>> Peter Hurley
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/pstore/ram.c: Fix the ramoops module parameters update

On 2015/3/9 15:39, Wang Long wrote:
cc: marco.storne...@gmail.com
cc: anton.voront...@linaro.org
cc: saly...@android.com
cc: ser...@chromium.org

 In the function ramoops_probe, the console_size, pmsg_size,
 ftrace_size may be update because the value is not the power
 of two. We should update the module parameter variables
 as well so they are visible through /sys/module/ramoops/parameters
 correctly.
 
 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  fs/pstore/ram.c | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
 index 5df325e..1aaa8dc 100644
 --- a/fs/pstore/ram.c
 +++ b/fs/pstore/ram.c
 @@ -559,6 +559,9 @@ pr_info([%s] pstore_register, __func__);
   mem_address = pdata-mem_address;
   record_size = pdata-record_size;
   dump_oops = pdata-dump_oops;
 + ramoops_console_size = pdata-console_size;
 + ramoops_pmsg_size = pdata-pmsg_size;
 + ramoops_ftrace_size = pdata-ftrace_size;
  
   pr_info(attached 0x%lx@0x%llx, ecc: %d/%d\n,
   cxt-size, (unsigned long long)cxt-phys_addr,
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

On 2015/3/7 11:01, Tim Kryger wrote:
 You only hit the silicon bug if you bombard the uart with characters
 and simultaneously request a baud rate or framing change.
 
 I'm not sure why you would do either to the uart console.  Is it
 possible your host machine is doing something weird?
 
 If you have the leverage, remind the SoC vendor to upgrade the serial
 block.  Synopsys fixed this a long time ago.
 
 -Tim

Hi, Tim

thanks for you reply. if we bombard the uart with characters and simultaneously
request a baud rate change, we hit the silicon bug.

Our scenario is to do stability testing（at the system booting, we bombard the 
uart
with characters）, With this version(v3.0.6) Synopsys Serial,  the expect are
print out the message(Couldn't set LCR to ) and the kernel will not hung.

Maybe the next release of the board we will upgrade the serial block to the new 
version.
but the issue is that how we circumvent this problem in kernel?

do you have any ideas? thanks.

Best Regards
Wang Long


 
 On Fri, Mar 6, 2015 at 8:50 AM, Peter Hurley pe...@hurleysoftware.com wrote:
 Hi Zhang,

 On 03/06/2015 04:11 AM, Zhang Zhen wrote:
 Hi,

   I'm testing 4.0-rc1 kernel on my board with 8250 Designware UART.(ARM 
 Cortex-a15 single core).

   I found if serial is busy and writes to the LCR failed after tried 
 1000 times.
   The kernel will hung up.

   The system boot success after changed from:

  95 static void dw8250_serial_out(struct uart_port *p, int offset, int 
 value)
  96 {
  97 struct dw8250_data *d = p-private_data;
  98
 ...
 ...
 112 writeb(value, p-membase + (UART_LCR  
 p-regshift));
 113 }
 114 dev_err(p-dev, Couldn't set LCR to %d\n, value);
 115 }
 116 }

   to:

  95 static void dw8250_serial_out(struct uart_port *p, int offset, int 
 value)
  96 {
  97 struct dw8250_data *d = p-private_data;
  98
 ...
 ...
 112 writeb(value, p-membase + (UART_LCR  
 p-regshift));
 113 }
 114 dev_info(p-dev, Couldn't set LCR to %d\n, value);
 //changed here
 115 }
 116 }

   The reason is serial8250_console_write can't get port-lock because 
 serial8250_do_set_termios has
   got port-lock.
   So i think here we should change from dev_err to dev_info ?

 That's not really going to help because this will still hang if the
 console_loglevel is set to  KERN_INFO.

   Any suggestions are welcome.

 Check that the port is not the uart_console() before logging the error,
 like;

 if (!uart_console(p))
 dev_err(p-dev, Couldn't .);

 Use a global flag to note the error and check it from other contexts.
 Plus, find out why you can't write LCR there.

 Also, consider re-designing how the 8250_dw driver implements that
 feature.

 Regards,
 Peter Hurley
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: 8250: remove the redundant include

On 2015/3/9 12:12, Wang Long wrote:
> The serial_core.h file have been included in header file
> serial_8250.h. so remove the "#include " in
> some 8250 serial drivers, because they have included the header file
> serial_8250.h.

missing the 8250_dw.c. i will send another patch.

Thanks
> 
> Signed-off-by: Wang Long 
> ---
>  drivers/tty/serial/8250/8250_core.c  | 1 -
>  drivers/tty/serial/8250/8250_early.c | 1 -
>  drivers/tty/serial/8250/8250_em.c| 1 -
>  drivers/tty/serial/8250/8250_hp300.c | 1 -
>  drivers/tty/serial/8250/8250_omap.c  | 1 -
>  5 files changed, 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index e3b9570a..7ddd668 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -31,7 +31,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tty/serial/8250/8250_early.c 
> b/drivers/tty/serial/8250/8250_early.c
> index c31a22b..c7ae647 100644
> --- a/drivers/tty/serial/8250/8250_early.c
> +++ b/drivers/tty/serial/8250/8250_early.c
> @@ -29,7 +29,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tty/serial/8250/8250_em.c 
> b/drivers/tty/serial/8250/8250_em.c
> index ae5eaed..0b63812 100644
> --- a/drivers/tty/serial/8250/8250_em.c
> +++ b/drivers/tty/serial/8250/8250_em.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tty/serial/8250/8250_hp300.c 
> b/drivers/tty/serial/8250/8250_hp300.c
> index b488208..2891958 100644
> --- a/drivers/tty/serial/8250/8250_hp300.c
> +++ b/drivers/tty/serial/8250/8250_hp300.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tty/serial/8250/8250_omap.c 
> b/drivers/tty/serial/8250/8250_omap.c
> index fe6d2e51..928 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update the of_selftest.txt

On 2015/3/6 22:40, Rob Herring wrote:
> On Mon, Mar 2, 2015 at 9:56 PM, Wang Long  wrote:
>> Since the directory "drivers/of/testcase-data" is renamed
>> to "drivers/of/unittest-data". so we should update the path
>> in the of_selftest.txt.
>>
>> When the kernel is build with OF_SELFTEST enabled, the output
> 
> s/build/built/
> 
> s/SELF/UNIT/

sorry for the mistakes.
> 
>> dtb is testcases.dtb instead of testcase.dtb, also update it
>> (s/testcase/testcases/).
>>
>> Signed-off-by: Wang Long 
>> ---
>>  Documentation/devicetree/of_selftest.txt | 22 +++---
> 
> Please rename to of_unittest.txt as well and rename occurrences of
> selftest to unittest.
> 
> Rob

OK

> 
>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/of_selftest.txt 
>> b/Documentation/devicetree/of_selftest.txt
>> index 57a808b..ffce144 100644
>> --- a/Documentation/devicetree/of_selftest.txt
>> +++ b/Documentation/devicetree/of_selftest.txt
>> @@ -22,31 +22,31 @@ most of the device drivers in various use cases.
>>
>>  2. Test-data
>>
>> -The Device Tree Source file (drivers/of/testcase-data/testcases.dts) 
>> contains
>> +The Device Tree Source file (drivers/of/unittest-data/testcases.dts) 
>> contains
>>  the test data required for executing the unit tests automated in
>> -drivers/of/selftests.c. Currently, following Device Tree Source Include 
>> files
>> -(.dtsi) are included in testcase.dts:
>> +drivers/of/unittest.c. Currently, following Device Tree Source Include files
>> +(.dtsi) are included in testcases.dts:
>>
>> -drivers/of/testcase-data/tests-interrupts.dtsi
>> -drivers/of/testcase-data/tests-platform.dtsi
>> -drivers/of/testcase-data/tests-phandle.dtsi
>> -drivers/of/testcase-data/tests-match.dtsi
>> +drivers/of/unittest-data/tests-interrupts.dtsi
>> +drivers/of/unittest-data/tests-platform.dtsi
>> +drivers/of/unittest-data/tests-phandle.dtsi
>> +drivers/of/unittest-data/tests-match.dtsi
>>
>>  When the kernel is build with OF_SELFTEST enabled, then the following make 
>> rule
>>
>>  $(obj)/%.dtb: $(src)/%.dts FORCE
>> $(call if_changed_dep, dtc)
>>
>> -is used to compile the DT source file (testcase.dts) into a binary blob
>> -(testcase.dtb), also referred as flattened DT.
>> +is used to compile the DT source file (testcases.dts) into a binary blob
>> +(testcases.dtb), also referred as flattened DT.
>>
>>  After that, using the following rule the binary blob above is wrapped as an
>> -assembly file (testcase.dtb.S).
>> +assembly file (testcases.dtb.S).
>>
>>  $(obj)/%.dtb.S: $(obj)/%.dtb
>> $(call cmd, dt_S_dtb)
>>
>> -The assembly file is compiled into an object file (testcase.dtb.o), and is
>> +The assembly file is compiled into an object file (testcases.dtb.o), and is
>>  linked into the kernel image.
>>
>>
>> --
>> 1.8.3.4
>>
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update the of_selftest.txt

On 2015/3/6 22:40, Rob Herring wrote:
 On Mon, Mar 2, 2015 at 9:56 PM, Wang Long long.wangl...@huawei.com wrote:
 Since the directory drivers/of/testcase-data is renamed
 to drivers/of/unittest-data. so we should update the path
 in the of_selftest.txt.

 When the kernel is build with OF_SELFTEST enabled, the output
 
 s/build/built/
 
 s/SELF/UNIT/

sorry for the mistakes.
 
 dtb is testcases.dtb instead of testcase.dtb, also update it
 (s/testcase/testcases/).

 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  Documentation/devicetree/of_selftest.txt | 22 +++---
 
 Please rename to of_unittest.txt as well and rename occurrences of
 selftest to unittest.
 
 Rob

OK

 
  1 file changed, 11 insertions(+), 11 deletions(-)

 diff --git a/Documentation/devicetree/of_selftest.txt 
 b/Documentation/devicetree/of_selftest.txt
 index 57a808b..ffce144 100644
 --- a/Documentation/devicetree/of_selftest.txt
 +++ b/Documentation/devicetree/of_selftest.txt
 @@ -22,31 +22,31 @@ most of the device drivers in various use cases.

  2. Test-data

 -The Device Tree Source file (drivers/of/testcase-data/testcases.dts) 
 contains
 +The Device Tree Source file (drivers/of/unittest-data/testcases.dts) 
 contains
  the test data required for executing the unit tests automated in
 -drivers/of/selftests.c. Currently, following Device Tree Source Include 
 files
 -(.dtsi) are included in testcase.dts:
 +drivers/of/unittest.c. Currently, following Device Tree Source Include files
 +(.dtsi) are included in testcases.dts:

 -drivers/of/testcase-data/tests-interrupts.dtsi
 -drivers/of/testcase-data/tests-platform.dtsi
 -drivers/of/testcase-data/tests-phandle.dtsi
 -drivers/of/testcase-data/tests-match.dtsi
 +drivers/of/unittest-data/tests-interrupts.dtsi
 +drivers/of/unittest-data/tests-platform.dtsi
 +drivers/of/unittest-data/tests-phandle.dtsi
 +drivers/of/unittest-data/tests-match.dtsi

  When the kernel is build with OF_SELFTEST enabled, then the following make 
 rule

  $(obj)/%.dtb: $(src)/%.dts FORCE
 $(call if_changed_dep, dtc)

 -is used to compile the DT source file (testcase.dts) into a binary blob
 -(testcase.dtb), also referred as flattened DT.
 +is used to compile the DT source file (testcases.dts) into a binary blob
 +(testcases.dtb), also referred as flattened DT.

  After that, using the following rule the binary blob above is wrapped as an
 -assembly file (testcase.dtb.S).
 +assembly file (testcases.dtb.S).

  $(obj)/%.dtb.S: $(obj)/%.dtb
 $(call cmd, dt_S_dtb)

 -The assembly file is compiled into an object file (testcase.dtb.o), and is
 +The assembly file is compiled into an object file (testcases.dtb.o), and is
  linked into the kernel image.


 --
 1.8.3.4

 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: 8250: remove the redundant include

On 2015/3/9 12:12, Wang Long wrote:
 The serial_core.h file have been included in header file
 serial_8250.h. so remove the #include serial_core.h in
 some 8250 serial drivers, because they have included the header file
 serial_8250.h.

missing the 8250_dw.c. i will send another patch.

Thanks
 
 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  drivers/tty/serial/8250/8250_core.c  | 1 -
  drivers/tty/serial/8250/8250_early.c | 1 -
  drivers/tty/serial/8250/8250_em.c| 1 -
  drivers/tty/serial/8250/8250_hp300.c | 1 -
  drivers/tty/serial/8250/8250_omap.c  | 1 -
  5 files changed, 5 deletions(-)
 
 diff --git a/drivers/tty/serial/8250/8250_core.c 
 b/drivers/tty/serial/8250/8250_core.c
 index e3b9570a..7ddd668 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -31,7 +31,6 @@
  #include linux/tty.h
  #include linux/ratelimit.h
  #include linux/tty_flip.h
 -#include linux/serial_core.h
  #include linux/serial.h
  #include linux/serial_8250.h
  #include linux/nmi.h
 diff --git a/drivers/tty/serial/8250/8250_early.c 
 b/drivers/tty/serial/8250/8250_early.c
 index c31a22b..c7ae647 100644
 --- a/drivers/tty/serial/8250/8250_early.c
 +++ b/drivers/tty/serial/8250/8250_early.c
 @@ -29,7 +29,6 @@
  #include linux/tty.h
  #include linux/init.h
  #include linux/console.h
 -#include linux/serial_core.h
  #include linux/serial_reg.h
  #include linux/serial.h
  #include linux/serial_8250.h
 diff --git a/drivers/tty/serial/8250/8250_em.c 
 b/drivers/tty/serial/8250/8250_em.c
 index ae5eaed..0b63812 100644
 --- a/drivers/tty/serial/8250/8250_em.c
 +++ b/drivers/tty/serial/8250/8250_em.c
 @@ -21,7 +21,6 @@
  #include linux/io.h
  #include linux/module.h
  #include linux/serial_8250.h
 -#include linux/serial_core.h
  #include linux/serial_reg.h
  #include linux/platform_device.h
  #include linux/clk.h
 diff --git a/drivers/tty/serial/8250/8250_hp300.c 
 b/drivers/tty/serial/8250/8250_hp300.c
 index b488208..2891958 100644
 --- a/drivers/tty/serial/8250/8250_hp300.c
 +++ b/drivers/tty/serial/8250/8250_hp300.c
 @@ -10,7 +10,6 @@
  #include linux/string.h
  #include linux/kernel.h
  #include linux/serial.h
 -#include linux/serial_core.h
  #include linux/serial_8250.h
  #include linux/delay.h
  #include linux/dio.h
 diff --git a/drivers/tty/serial/8250/8250_omap.c 
 b/drivers/tty/serial/8250/8250_omap.c
 index fe6d2e51..928 100644
 --- a/drivers/tty/serial/8250/8250_omap.c
 +++ b/drivers/tty/serial/8250/8250_omap.c
 @@ -11,7 +11,6 @@
  #include linux/io.h
  #include linux/module.h
  #include linux/serial_8250.h
 -#include linux/serial_core.h
  #include linux/serial_reg.h
  #include linux/tty_flip.h
  #include linux/platform_device.h
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] test-hexdump: test the return value of the hex_dump_to_buffer

2015-02-25 Thread long.wanglong

On 2015/2/16 17:47, Andy Shevchenko wrote:
> On Sun, 2015-02-15 at 09:50 +, Wang Long wrote:
>> As the function hex_dump_to_buffer returns the amount of bytes placed
>> in the buffer without terminating NUL. the test-hexdump should test
>> the return value of it.
> 
> I don't think it's needed. When the prototype was changed the new test
> case had been introduced to cover the overflow cases, i.e.
> test_hexdump_overflow().
> 

ok, thanks.

>>
>> Signed-off-by: Wang Long 
>> ---
>>  lib/test-hexdump.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/test-hexdump.c b/lib/test-hexdump.c
>> index daf29a39..9243be7 100644
>> --- a/lib/test-hexdump.c
>> +++ b/lib/test-hexdump.c
>> @@ -52,8 +52,9 @@ static void __init test_hexdump(size_t len, int rowsize, 
>> int groupsize,
>>  size_t l = len;
>>  int gs = groupsize, rs = rowsize;
>>  unsigned int i;
>> +int r;
>>  
>> -hex_dump_to_buffer(data_b, l, rs, gs, real, sizeof(real), ascii);
>> +r = hex_dump_to_buffer(data_b, l, rs, gs, real, sizeof(real), ascii);
>>  
>>  if (rs != 16 && rs != 32)
>>  rs = 16;
>> @@ -96,7 +97,7 @@ static void __init test_hexdump(size_t len, int rowsize, 
>> int groupsize,
>>  
>>  *p = '\0';
>>  
>> -if (strcmp(test, real)) {
>> +if (strcmp(test, real) || r != strlen(real)) {
>>  pr_err("Len: %zu row: %d group: %d\n", len, rowsize, groupsize);
>>  pr_err("Result: '%s'\n", real);
>>  pr_err("Expect: '%s'\n", test);
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] test-hexdump: test the return value of the hex_dump_to_buffer

2015-02-25 Thread long.wanglong

On 2015/2/16 17:47, Andy Shevchenko wrote:
 On Sun, 2015-02-15 at 09:50 +, Wang Long wrote:
 As the function hex_dump_to_buffer returns the amount of bytes placed
 in the buffer without terminating NUL. the test-hexdump should test
 the return value of it.
 
 I don't think it's needed. When the prototype was changed the new test
 case had been introduced to cover the overflow cases, i.e.
 test_hexdump_overflow().
 

ok, thanks.


 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  lib/test-hexdump.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/lib/test-hexdump.c b/lib/test-hexdump.c
 index daf29a39..9243be7 100644
 --- a/lib/test-hexdump.c
 +++ b/lib/test-hexdump.c
 @@ -52,8 +52,9 @@ static void __init test_hexdump(size_t len, int rowsize, 
 int groupsize,
  size_t l = len;
  int gs = groupsize, rs = rowsize;
  unsigned int i;
 +int r;
  
 -hex_dump_to_buffer(data_b, l, rs, gs, real, sizeof(real), ascii);
 +r = hex_dump_to_buffer(data_b, l, rs, gs, real, sizeof(real), ascii);
  
  if (rs != 16  rs != 32)
  rs = 16;
 @@ -96,7 +97,7 @@ static void __init test_hexdump(size_t len, int rowsize, 
 int groupsize,
  
  *p = '\0';
  
 -if (strcmp(test, real)) {
 +if (strcmp(test, real) || r != strlen(real)) {
  pr_err(Len: %zu row: %d group: %d\n, len, rowsize, groupsize);
  pr_err(Result: '%s'\n, real);
  pr_err(Expect: '%s'\n, test);
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SAMPLES: kprobe_example: Make it print something on ARM.

On 2015/2/4 11:17, Masami Hiramatsu wrote:
> (2015/02/04 11:56), Wang Long wrote:
>> This KProbes example is a little useless if it doesn't print anything.
>> For ARM print similar messages to those produced on x86 and PPC.
> 
> BTW, I guess similar update required for s390, doesn't it?
> 

yes, because i am not familiar with s390, someone else may update this example 
for s390.

Best Regards
Wang Long

>>
>> Signed-off-by: Wang Long 
> 
> Acked-by: Masami Hiramatsu 
> 
> Thank you!
> 
>> ---
>>  samples/kprobes/kprobe_example.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/samples/kprobes/kprobe_example.c 
>> b/samples/kprobes/kprobe_example.c
>> index 366db1a..eba9f1a 100644
>> --- a/samples/kprobes/kprobe_example.c
>> +++ b/samples/kprobes/kprobe_example.c
>> @@ -42,6 +42,11 @@ static int handler_pre(struct kprobe *p, struct pt_regs 
>> *regs)
>>  " ex1 = 0x%lx\n",
>>  p->addr, regs->pc, regs->ex1);
>>  #endif
>> +#ifdef CONFIG_ARM
>> +printk(KERN_INFO "pre_handler: p->addr = 0x%p, ARM_pc = 0x%lx,"
>> +" ARM_cpsr = 0x%lx\n",
>> +p->addr, regs->ARM_pc, regs->ARM_cpsr);
>> +#endif
>>  
>>  /* A dump_stack() here will give a stack backtrace */
>>  return 0;
>> @@ -67,6 +72,10 @@ static void handler_post(struct kprobe *p, struct pt_regs 
>> *regs,
>>  printk(KERN_INFO "post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
>>  p->addr, regs->ex1);
>>  #endif
>> +#ifdef CONFIG_ARM
>> +printk(KERN_INFO "post_handler: p->addr = 0x%p, ARM_cpsr = 0x%lx\n",
>> +p->addr, regs->ARM_cpsr);
>> +#endif
>>  }
>>  
>>  /*
>>
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] samples: Fix `echo 1 > /proc/int-fifo` never return error

On 2015/2/4 18:18, Stefani Seibold wrote:
> The example is intended for int types, not for strings. So it is not a
> bug, it's a feature ;-) But anyway, if you prefer to handle with strings
> your are okay by me.
> 
hi,Stefani Seibold

Thanks you for your reply. another question?

This example export the interface '/proc/int-fifo', and how to use it?
Write and read it through system call, or the command `cat` and `echo`?

Best Regards
Wang Long

> Am Dienstag, den 03.02.2015, 11:51 + schrieb Wang Long:
>> echo 99 > /proc/int-fifo   > Never return
>> echo 1000 > /proc/int-fifo > Never return
>>
>> this patch fix it.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  samples/kfifo/inttype-example.c | 51 
>> -
>>  1 file changed, 40 insertions(+), 11 deletions(-)
>>
>> diff --git a/samples/kfifo/inttype-example.c 
>> b/samples/kfifo/inttype-example.c
>> index 8dc3c2e..cc0db5f 100644
>> --- a/samples/kfifo/inttype-example.c
>> +++ b/samples/kfifo/inttype-example.c
>> @@ -6,6 +6,7 @@
>>   * Released under the GPL version 2 only.
>>   *
>>   */
>> +#include 
>>  
>>  #include 
>>  #include 
>> @@ -23,6 +24,9 @@
>>  /* name of the proc entry */
>>  #define PROC_FIFO   "int-fifo"
>>  
>> +/* Worst case buffer size needed for holding an integer. */
>> +#define PROC_NUMBUF 13
>> +
>>  /* lock for procfs read access */
>>  static DEFINE_MUTEX(read_lock);
>>  
>> @@ -108,33 +112,58 @@ static int __init testfunc(void)
>>  static ssize_t fifo_write(struct file *file, const char __user *buf,
>>  size_t count, loff_t *ppos)
>>  {
>> -int ret;
>> -unsigned int copied;
>> +char buffer[PROC_NUMBUF];
>> +int value;
>> +int err;
>>  
>> -if (mutex_lock_interruptible(_lock))
>> -return -ERESTARTSYS;
>> +memset(buffer, 0, sizeof(buffer));
>>  
>> -ret = kfifo_from_user(, buf, count, );
>> +if (count > sizeof(buffer) - 1)
>> +count = sizeof(buffer) - 1;
>> +if (copy_from_user(buffer, buf, count)) {
>> +err = -EFAULT;
>> +goto out;
>> +}
>>  
>> -mutex_unlock(_lock);
>> +err = kstrtoint(strstrip(buffer), 0, );
>> +if (err)
>> +goto out;
>> +
>> +if (kfifo_is_full()) {
>> +err = -EINVAL;
>> +goto out;
>> +}
>>  
>> -return ret ? ret : copied;
>> +if (mutex_lock_interruptible(_lock))
>> +return -ERESTARTSYS;
>> +kfifo_put(, value);
>> +mutex_unlock(_lock);
>> +out:
>> +return err < 0 ? err : count;
>>  }
>>  
>>  static ssize_t fifo_read(struct file *file, char __user *buf,
>>  size_t count, loff_t *ppos)
>>  {
>> -int ret;
>> -unsigned int copied;
>> +char buffer[PROC_NUMBUF * FIFO_SIZE];
>> +int value;
>> +size_t  len = 0;
>> +ssize_t ret = -1;
>> +
>> +memset(buffer, 0, sizeof(buffer));
>>  
>>  if (mutex_lock_interruptible(_lock))
>>  return -ERESTARTSYS;
>>  
>> -ret = kfifo_to_user(, buf, count, );
>> +while (!kfifo_is_empty()){
>> +ret = kfifo_get(, );
>> +len = snprintf(buffer, sizeof(buffer), "%s%d\n", buffer, value);
>> +}
>>  
>>  mutex_unlock(_lock);
>> +ret = copy_to_user(buf, buffer, len);
>>  
>> -return ret ? ret : copied;
>> +return ret ? ret : len;
>>  }
>>  
>>  static const struct file_operations fifo_fops = {
> 
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SAMPLES: kprobe_example: Make it print something on ARM.

On 2015/2/4 11:17, Masami Hiramatsu wrote:
 (2015/02/04 11:56), Wang Long wrote:
 This KProbes example is a little useless if it doesn't print anything.
 For ARM print similar messages to those produced on x86 and PPC.
 
 BTW, I guess similar update required for s390, doesn't it?
 

yes, because i am not familiar with s390, someone else may update this example 
for s390.

Best Regards
Wang Long


 Signed-off-by: Wang Long long.wangl...@huawei.com
 
 Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
 
 Thank you!
 
 ---
  samples/kprobes/kprobe_example.c | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/samples/kprobes/kprobe_example.c 
 b/samples/kprobes/kprobe_example.c
 index 366db1a..eba9f1a 100644
 --- a/samples/kprobes/kprobe_example.c
 +++ b/samples/kprobes/kprobe_example.c
 @@ -42,6 +42,11 @@ static int handler_pre(struct kprobe *p, struct pt_regs 
 *regs)
   ex1 = 0x%lx\n,
  p-addr, regs-pc, regs-ex1);
  #endif
 +#ifdef CONFIG_ARM
 +printk(KERN_INFO pre_handler: p-addr = 0x%p, ARM_pc = 0x%lx,
 + ARM_cpsr = 0x%lx\n,
 +p-addr, regs-ARM_pc, regs-ARM_cpsr);
 +#endif
  
  /* A dump_stack() here will give a stack backtrace */
  return 0;
 @@ -67,6 +72,10 @@ static void handler_post(struct kprobe *p, struct pt_regs 
 *regs,
  printk(KERN_INFO post_handler: p-addr = 0x%p, ex1 = 0x%lx\n,
  p-addr, regs-ex1);
  #endif
 +#ifdef CONFIG_ARM
 +printk(KERN_INFO post_handler: p-addr = 0x%p, ARM_cpsr = 0x%lx\n,
 +p-addr, regs-ARM_cpsr);
 +#endif
  }
  
  /*

 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] samples: Fix `echo 1 /proc/int-fifo` never return error

On 2015/2/4 18:18, Stefani Seibold wrote:
 The example is intended for int types, not for strings. So it is not a
 bug, it's a feature ;-) But anyway, if you prefer to handle with strings
 your are okay by me.
 
hi,Stefani Seibold

Thanks you for your reply. another question?

This example export the interface '/proc/int-fifo', and how to use it?
Write and read it through system call, or the command `cat` and `echo`?

Best Regards
Wang Long

 Am Dienstag, den 03.02.2015, 11:51 + schrieb Wang Long:
 echo 99  /proc/int-fifo    Never return
 echo 1000  /proc/int-fifo  Never return

 this patch fix it.

 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  samples/kfifo/inttype-example.c | 51 
 -
  1 file changed, 40 insertions(+), 11 deletions(-)

 diff --git a/samples/kfifo/inttype-example.c 
 b/samples/kfifo/inttype-example.c
 index 8dc3c2e..cc0db5f 100644
 --- a/samples/kfifo/inttype-example.c
 +++ b/samples/kfifo/inttype-example.c
 @@ -6,6 +6,7 @@
   * Released under the GPL version 2 only.
   *
   */
 +#include asm/uaccess.h
  
  #include linux/init.h
  #include linux/module.h
 @@ -23,6 +24,9 @@
  /* name of the proc entry */
  #define PROC_FIFO   int-fifo
  
 +/* Worst case buffer size needed for holding an integer. */
 +#define PROC_NUMBUF 13
 +
  /* lock for procfs read access */
  static DEFINE_MUTEX(read_lock);
  
 @@ -108,33 +112,58 @@ static int __init testfunc(void)
  static ssize_t fifo_write(struct file *file, const char __user *buf,
  size_t count, loff_t *ppos)
  {
 -int ret;
 -unsigned int copied;
 +char buffer[PROC_NUMBUF];
 +int value;
 +int err;
  
 -if (mutex_lock_interruptible(write_lock))
 -return -ERESTARTSYS;
 +memset(buffer, 0, sizeof(buffer));
  
 -ret = kfifo_from_user(test, buf, count, copied);
 +if (count  sizeof(buffer) - 1)
 +count = sizeof(buffer) - 1;
 +if (copy_from_user(buffer, buf, count)) {
 +err = -EFAULT;
 +goto out;
 +}
  
 -mutex_unlock(write_lock);
 +err = kstrtoint(strstrip(buffer), 0, value);
 +if (err)
 +goto out;
 +
 +if (kfifo_is_full(test)) {
 +err = -EINVAL;
 +goto out;
 +}
  
 -return ret ? ret : copied;
 +if (mutex_lock_interruptible(write_lock))
 +return -ERESTARTSYS;
 +kfifo_put(test, value);
 +mutex_unlock(write_lock);
 +out:
 +return err  0 ? err : count;
  }
  
  static ssize_t fifo_read(struct file *file, char __user *buf,
  size_t count, loff_t *ppos)
  {
 -int ret;
 -unsigned int copied;
 +char buffer[PROC_NUMBUF * FIFO_SIZE];
 +int value;
 +size_t  len = 0;
 +ssize_t ret = -1;
 +
 +memset(buffer, 0, sizeof(buffer));
  
  if (mutex_lock_interruptible(read_lock))
  return -ERESTARTSYS;
  
 -ret = kfifo_to_user(test, buf, count, copied);
 +while (!kfifo_is_empty(test)){
 +ret = kfifo_get(test, value);
 +len = snprintf(buffer, sizeof(buffer), %s%d\n, buffer, value);
 +}
  
  mutex_unlock(read_lock);
 +ret = copy_to_user(buf, buffer, len);
  
 -return ret ? ret : copied;
 +return ret ? ret : len;
  }
  
  static const struct file_operations fifo_fops = {
 
 
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Using squashfs, kernel will hung task with no free memory?

2015-01-22 Thread long.wanglong

On 2015/1/23 2:19, Phillip Lougher wrote:
> On 22/01/15 02:28, long.wanglong wrote:
>> hi，
>>
>> I have encountered kernel hung task when running stability and stress test.
>>
>> test scenarios:
>> 1)the kernel hungtask settings are following:
>> hung_task_panic = 1
>> hung_task_timeout_secs = 120
>> 2)the rootfs type is squashfs(read-only)
>> 
>> what the test does is to fork many child process and each process will alloc 
>> memory.
>> when there is no free memory in the system, OOM killer is triggerred. and 
>> then the kernel triggers hung task(after about five  minutes) .
>> the reason for hung task is that some process keep D states for 120 seconds.
>>
>> if there is no free memory in the system, many process state is D, they 
>> enter into D state by kernel path  `squashfs_cache_get()--->wait_event()`.
>> the backtrace is:
>>
>> [  313.950118] [] (__schedule+0x448/0x5cc) from [] 
>> (squashfs_cache_get+0x120/0x3ec)
>> [  314.059660] [] (squashfs_cache_get+0x120/0x3ec) from 
>> [] (squashfs_readpage+0x748/0xa2c)
>> [  314.176497] [] (squashfs_readpage+0x748/0xa2c) from 
>> [] (__do_page_cache_readahead+0x1ac/0x200)
>> [  314.300621] [] (__do_page_cache_readahead+0x1ac/0x200) from 
>> [] (ra_submit+0x24/0x28)
>> [  314.414325] [] (ra_submit+0x24/0x28) from [] 
>> (filemap_fault+0x16c/0x3f0)
>> [  314.515521] [] (filemap_fault+0x16c/0x3f0) from [] 
>> (__do_fault+0xc0/0x570)
>> [  314.618802] [] (__do_fault+0xc0/0x570) from [] 
>> (handle_pte_fault+0x47c/0x1048)
>> [  314.726250] [] (handle_pte_fault+0x47c/0x1048) from 
>> [] (handle_mm_fault+0x164/0x218)
>> [  314.839959] [] (handle_mm_fault+0x164/0x218) from [] 
>> (do_page_fault.part.7+0x108/0x360)
>> [  314.956788] [] (do_page_fault.part.7+0x108/0x360) from 
>> [] (do_page_fault+0x2c/0x70)
>> [  315.069442] [] (do_page_fault+0x2c/0x70) from [] 
>> (do_PrefetchAbort+0x2c/0x90)
>> [  315.175850] [] (do_PrefetchAbort+0x2c/0x90) from [] 
>> (ret_from_exception+0x0/0x10)
>>
>> when a task is already exiting because of OOM killer,the next time OOM 
>> killer will kill the same task.
>> so, if the first time of OOM killer select a task(A) that in D state (the 
>> task ingore exit signal beacuse of D state).
>> then the next time of OOM killer will also kill task A. In this scenario, 
>> oom killer will not free memory.
>>
>> with no free memory, many process sleep in function squashfs_cache_get. 
>> about 2 minutes, the system hung task and panic.
>> because of OOM feature and squashfs, on heavy system, This problem is easily 
>> reproduce.
>>
>> Is this a problem about squashfs or about the OOM killer. Can anyone give me 
>> some good ideas about this?
> 
> This is not a Squashfs issue, it is a well known problem with
> the OOM killer trying to kill tasks which are slow to exit (being
> in D state).  Just google "OOM hung task" to see how long this
> issue has been around.
> 
> The OOM killer is worse than useless in embedded systems because
> its behaviour is unpredictable and can leave a system in a
> zombified or half zombified state. Due to this reason many
> embedded systems disable the OOM killer entirely, and ensure
> there is adequate memory backed up by a watchdog which reboots
> a hung system.
> 
> Phillip
> 

Thanks

>>
>> Best Regards
>> Wang Long
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> .
>>
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Using squashfs, kernel will hung task with no free memory?

2015-01-22 Thread long.wanglong

On 2015/1/23 2:19, Phillip Lougher wrote:
 On 22/01/15 02:28, long.wanglong wrote:
 hi，

 I have encountered kernel hung task when running stability and stress test.

 test scenarios:
 1)the kernel hungtask settings are following:
 hung_task_panic = 1
 hung_task_timeout_secs = 120
 2)the rootfs type is squashfs(read-only)
 
 what the test does is to fork many child process and each process will alloc 
 memory.
 when there is no free memory in the system, OOM killer is triggerred. and 
 then the kernel triggers hung task(after about five  minutes) .
 the reason for hung task is that some process keep D states for 120 seconds.

 if there is no free memory in the system, many process state is D, they 
 enter into D state by kernel path  `squashfs_cache_get()---wait_event()`.
 the backtrace is:

 [  313.950118] [c02d2014] (__schedule+0x448/0x5cc) from [c014e510] 
 (squashfs_cache_get+0x120/0x3ec)
 [  314.059660] [c014e510] (squashfs_cache_get+0x120/0x3ec) from 
 [c014fd1c] (squashfs_readpage+0x748/0xa2c)
 [  314.176497] [c014fd1c] (squashfs_readpage+0x748/0xa2c) from 
 [c00b7be0] (__do_page_cache_readahead+0x1ac/0x200)
 [  314.300621] [c00b7be0] (__do_page_cache_readahead+0x1ac/0x200) from 
 [c00b7e98] (ra_submit+0x24/0x28)
 [  314.414325] [c00b7e98] (ra_submit+0x24/0x28) from [c00b043c] 
 (filemap_fault+0x16c/0x3f0)
 [  314.515521] [c00b043c] (filemap_fault+0x16c/0x3f0) from [c00c94e0] 
 (__do_fault+0xc0/0x570)
 [  314.618802] [c00c94e0] (__do_fault+0xc0/0x570) from [c00cbdc4] 
 (handle_pte_fault+0x47c/0x1048)
 [  314.726250] [c00cbdc4] (handle_pte_fault+0x47c/0x1048) from 
 [c00cd928] (handle_mm_fault+0x164/0x218)
 [  314.839959] [c00cd928] (handle_mm_fault+0x164/0x218) from [c02d4878] 
 (do_page_fault.part.7+0x108/0x360)
 [  314.956788] [c02d4878] (do_page_fault.part.7+0x108/0x360) from 
 [c02d4afc] (do_page_fault+0x2c/0x70)
 [  315.069442] [c02d4afc] (do_page_fault+0x2c/0x70) from [c00084cc] 
 (do_PrefetchAbort+0x2c/0x90)
 [  315.175850] [c00084cc] (do_PrefetchAbort+0x2c/0x90) from [c02d3674] 
 (ret_from_exception+0x0/0x10)

 when a task is already exiting because of OOM killer,the next time OOM 
 killer will kill the same task.
 so, if the first time of OOM killer select a task(A) that in D state (the 
 task ingore exit signal beacuse of D state).
 then the next time of OOM killer will also kill task A. In this scenario, 
 oom killer will not free memory.

 with no free memory, many process sleep in function squashfs_cache_get. 
 about 2 minutes, the system hung task and panic.
 because of OOM feature and squashfs, on heavy system, This problem is easily 
 reproduce.

 Is this a problem about squashfs or about the OOM killer. Can anyone give me 
 some good ideas about this?
 
 This is not a Squashfs issue, it is a well known problem with
 the OOM killer trying to kill tasks which are slow to exit (being
 in D state).  Just google OOM hung task to see how long this
 issue has been around.
 
 The OOM killer is worse than useless in embedded systems because
 its behaviour is unpredictable and can leave a system in a
 zombified or half zombified state. Due to this reason many
 embedded systems disable the OOM killer entirely, and ensure
 there is adequate memory backed up by a watchdog which reboots
 a hung system.
 
 Phillip
 

Thanks


 Best Regards
 Wang Long









 .

 
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] Using squashfs, kernel will hung task with no free memory?

2015-01-21 Thread long.wanglong

hi，

I have encountered kernel hung task when running stability and stress test.

test scenarios:
1)the kernel hungtask settings are following:
hung_task_panic = 1
hung_task_timeout_secs = 120
2)the rootfs type is squashfs(read-only)

what the test does is to fork many child process and each process will alloc 
memory.
when there is no free memory in the system, OOM killer is triggerred. and then 
the kernel triggers hung task(after about five  minutes) .
the reason for hung task is that some process keep D states for 120 seconds.

if there is no free memory in the system, many process state is D, they enter 
into D state by kernel path  `squashfs_cache_get()--->wait_event()`.
the backtrace is:

[  313.950118] [] (__schedule+0x448/0x5cc) from [] 
(squashfs_cache_get+0x120/0x3ec)
[  314.059660] [] (squashfs_cache_get+0x120/0x3ec) from [] 
(squashfs_readpage+0x748/0xa2c)
[  314.176497] [] (squashfs_readpage+0x748/0xa2c) from [] 
(__do_page_cache_readahead+0x1ac/0x200)
[  314.300621] [] (__do_page_cache_readahead+0x1ac/0x200) from 
[] (ra_submit+0x24/0x28)
[  314.414325] [] (ra_submit+0x24/0x28) from [] 
(filemap_fault+0x16c/0x3f0)
[  314.515521] [] (filemap_fault+0x16c/0x3f0) from [] 
(__do_fault+0xc0/0x570)
[  314.618802] [] (__do_fault+0xc0/0x570) from [] 
(handle_pte_fault+0x47c/0x1048)
[  314.726250] [] (handle_pte_fault+0x47c/0x1048) from [] 
(handle_mm_fault+0x164/0x218)
[  314.839959] [] (handle_mm_fault+0x164/0x218) from [] 
(do_page_fault.part.7+0x108/0x360)
[  314.956788] [] (do_page_fault.part.7+0x108/0x360) from 
[] (do_page_fault+0x2c/0x70)
[  315.069442] [] (do_page_fault+0x2c/0x70) from [] 
(do_PrefetchAbort+0x2c/0x90)
[  315.175850] [] (do_PrefetchAbort+0x2c/0x90) from [] 
(ret_from_exception+0x0/0x10)

when a task is already exiting because of OOM killer,the next time OOM killer 
will kill the same task.
so, if the first time of OOM killer select a task(A) that in D state (the task 
ingore exit signal beacuse of D state).
then the next time of OOM killer will also kill task A. In this scenario, oom 
killer will not free memory.

with no free memory, many process sleep in function squashfs_cache_get. about 2 
minutes, the system hung task and panic.
because of OOM feature and squashfs, on heavy system, This problem is easily 
reproduce.

Is this a problem about squashfs or about the OOM killer. Can anyone give me 
some good ideas about this?

Best Regards
Wang Long









--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] Using squashfs, kernel will hung task with no free memory?

2015-01-21 Thread long.wanglong

hi，

I have encountered kernel hung task when running stability and stress test.

test scenarios:
1)the kernel hungtask settings are following:
hung_task_panic = 1
hung_task_timeout_secs = 120
2)the rootfs type is squashfs(read-only)

what the test does is to fork many child process and each process will alloc 
memory.
when there is no free memory in the system, OOM killer is triggerred. and then 
the kernel triggers hung task(after about five  minutes) .
the reason for hung task is that some process keep D states for 120 seconds.

if there is no free memory in the system, many process state is D, they enter 
into D state by kernel path  `squashfs_cache_get()---wait_event()`.
the backtrace is:

[  313.950118] [c02d2014] (__schedule+0x448/0x5cc) from [c014e510] 
(squashfs_cache_get+0x120/0x3ec)
[  314.059660] [c014e510] (squashfs_cache_get+0x120/0x3ec) from [c014fd1c] 
(squashfs_readpage+0x748/0xa2c)
[  314.176497] [c014fd1c] (squashfs_readpage+0x748/0xa2c) from [c00b7be0] 
(__do_page_cache_readahead+0x1ac/0x200)
[  314.300621] [c00b7be0] (__do_page_cache_readahead+0x1ac/0x200) from 
[c00b7e98] (ra_submit+0x24/0x28)
[  314.414325] [c00b7e98] (ra_submit+0x24/0x28) from [c00b043c] 
(filemap_fault+0x16c/0x3f0)
[  314.515521] [c00b043c] (filemap_fault+0x16c/0x3f0) from [c00c94e0] 
(__do_fault+0xc0/0x570)
[  314.618802] [c00c94e0] (__do_fault+0xc0/0x570) from [c00cbdc4] 
(handle_pte_fault+0x47c/0x1048)
[  314.726250] [c00cbdc4] (handle_pte_fault+0x47c/0x1048) from [c00cd928] 
(handle_mm_fault+0x164/0x218)
[  314.839959] [c00cd928] (handle_mm_fault+0x164/0x218) from [c02d4878] 
(do_page_fault.part.7+0x108/0x360)
[  314.956788] [c02d4878] (do_page_fault.part.7+0x108/0x360) from 
[c02d4afc] (do_page_fault+0x2c/0x70)
[  315.069442] [c02d4afc] (do_page_fault+0x2c/0x70) from [c00084cc] 
(do_PrefetchAbort+0x2c/0x90)
[  315.175850] [c00084cc] (do_PrefetchAbort+0x2c/0x90) from [c02d3674] 
(ret_from_exception+0x0/0x10)

when a task is already exiting because of OOM killer,the next time OOM killer 
will kill the same task.
so, if the first time of OOM killer select a task(A) that in D state (the task 
ingore exit signal beacuse of D state).
then the next time of OOM killer will also kill task A. In this scenario, oom 
killer will not free memory.

with no free memory, many process sleep in function squashfs_cache_get. about 2 
minutes, the system hung task and panic.
because of OOM feature and squashfs, on heavy system, This problem is easily 
reproduce.

Is this a problem about squashfs or about the OOM killer. Can anyone give me 
some good ideas about this?

Best Regards
Wang Long









--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: does the semantics of MAP_LOCKED is equal to mlock() function?

2015-01-19 Thread long.wanglong

On 2015/1/19 19:01, Michal Hocko wrote:
> On Mon 19-01-15 10:46:56, Michal Hocko wrote:
> [...]
>>> testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)
>>>
>>> 185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
>>> 186  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
>>> 187 if (p == MAP_FAILED)
>>> 188 err(1, "mmap(lock) failed");
>>> 189
>>> 190 if (mlock(p, memsize) == -1)
>>> 191 err(1, "mlock failed")
>>>
>>> expect: invoke OOM killer.
>>> result: invoke OOM killer.
> 
> Are you sure about this? memcg OOM killer shouldn't trigger even from
> mlock path. It should just lead to ENOMEM. If you see the OOM killer
> then it is probably coming from a page fault from a different source.
> strace of your test would tell you more.
> 
hi, Michal Hocko

sorry for the wrong description in the email. i run the two testcase in kernel 
v3.10.63, not
the latest kernel.

in kernel v3.18, the two testcases can not invoke OOM killer.

The problem comes from the LTP tests, because the v3.10.61 lts apply the 
following patch:

f8a5117916dd2871c056963bf5ee0d1101c10099 mm: memcg: handle non-error OOM 
situations more gracefully
f79d6a468980516cbfb9e01313c846b82b9d2e7e mm: memcg: do not trap chargers with 
full callstack on OOM
7a147e0c45a8fa198ade4128bdcbf8592f48843e mm: memcg: rework and document OOM 
waiting and wakeup
11f34787b50ce71f66b85ad8790beaa5eee3f897 mm: memcg: enable memcg OOM killer 
only for user faults

as you said in: http://marc.info/?l=linux-api=142122902613316=2

"
The primary issue is that mmap doesn't report a failure if MAP_LOCKED fails to 
populate the area. Is
this the correct/expected behavior?
"

There is another problem:

in kernel v3.10.63  testcase 1 can not invoke OOM, but testcase2 can invoke OOM.
in kernel v3.18 both testcase 1 and testcase 2 can not invoke OOM.

in kernel v3.10.63, why testcase2  can invoke OOM killer?

Thanks


Best Regards
Wang Long










--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: does the semantics of MAP_LOCKED is equal to mlock() function?

2015-01-19 Thread long.wanglong

On 2015/1/19 19:01, Michal Hocko wrote:
 On Mon 19-01-15 10:46:56, Michal Hocko wrote:
 [...]
 testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)

 185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
 186  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
 187 if (p == MAP_FAILED)
 188 err(1, mmap(lock) failed);
 189
 190 if (mlock(p, memsize) == -1)
 191 err(1, mlock failed)

 expect: invoke OOM killer.
 result: invoke OOM killer.
 
 Are you sure about this? memcg OOM killer shouldn't trigger even from
 mlock path. It should just lead to ENOMEM. If you see the OOM killer
 then it is probably coming from a page fault from a different source.
 strace of your test would tell you more.
 
hi, Michal Hocko

sorry for the wrong description in the email. i run the two testcase in kernel 
v3.10.63, not
the latest kernel.

in kernel v3.18, the two testcases can not invoke OOM killer.

The problem comes from the LTP tests, because the v3.10.61 lts apply the 
following patch:

f8a5117916dd2871c056963bf5ee0d1101c10099 mm: memcg: handle non-error OOM 
situations more gracefully
f79d6a468980516cbfb9e01313c846b82b9d2e7e mm: memcg: do not trap chargers with 
full callstack on OOM
7a147e0c45a8fa198ade4128bdcbf8592f48843e mm: memcg: rework and document OOM 
waiting and wakeup
11f34787b50ce71f66b85ad8790beaa5eee3f897 mm: memcg: enable memcg OOM killer 
only for user faults

as you said in: http://marc.info/?l=linux-apim=142122902613316w=2


The primary issue is that mmap doesn't report a failure if MAP_LOCKED fails to 
populate the area. Is
this the correct/expected behavior?


There is another problem:

in kernel v3.10.63  testcase 1 can not invoke OOM, but testcase2 can invoke OOM.
in kernel v3.18 both testcase 1 and testcase 2 can not invoke OOM.

in kernel v3.10.63, why testcase2  can invoke OOM killer?

Thanks


Best Regards
Wang Long










--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

does the semantics of MAP_LOCKED is equal to mlock() function?

2015-01-18 Thread long.wanglong

Hi all:

In the latest kernel, i set the memory limit (4096) in a test cgroup. and add 
the test task.
the test code code is:

testcase 1: mmap with MAP_LOCKED flag(memsize = 8192)

185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
186  MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0);
187 if (p == MAP_FAILED)
188 err(1, "mmap(lock) failed");

expect: invoke OOM killer.
result: not invoke OOM killer.


testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)

185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
186  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
187 if (p == MAP_FAILED)
188 err(1, "mmap(lock) failed");
189
190 if (mlock(p, memsize) == -1)
191 err(1, "mlock failed")

expect: invoke OOM killer.
result: invoke OOM killer.

in the Linux Programmer's Manual:

MAP_LOCKED (since Linux 2.5.37)
Lock the pages of the mapped region into memory in the manner
of mlock(2).  This flag is ignored in older kernels.

and
   mlock() locks pages in the address range starting at addr and
   continuing for len bytes.  All pages that contain a part of the
   specified address range are guaranteed to be resident in RAM when the
   call returns successfully; the pages are guaranteed to stay in RAM
   until later unlocked.

According to the description in the manual, the two testcases are equivalent.

why the first testcase does not invoke OOM killer?
does the mmap with MAP_LOCKED flag will not immediately allocate physical 
memory?


Best Regards
Wang Long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

does the semantics of MAP_LOCKED is equal to mlock() function?

2015-01-18 Thread long.wanglong

Hi all:

In the latest kernel, i set the memory limit (4096) in a test cgroup. and add 
the test task.
the test code code is:

testcase 1: mmap with MAP_LOCKED flag(memsize = 8192)

185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
186  MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0);
187 if (p == MAP_FAILED)
188 err(1, mmap(lock) failed);

expect: invoke OOM killer.
result: not invoke OOM killer.


testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)

185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
186  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
187 if (p == MAP_FAILED)
188 err(1, mmap(lock) failed);
189
190 if (mlock(p, memsize) == -1)
191 err(1, mlock failed)

expect: invoke OOM killer.
result: invoke OOM killer.

in the Linux Programmer's Manual:

MAP_LOCKED (since Linux 2.5.37)
Lock the pages of the mapped region into memory in the manner
of mlock(2).  This flag is ignored in older kernels.

and
   mlock() locks pages in the address range starting at addr and
   continuing for len bytes.  All pages that contain a part of the
   specified address range are guaranteed to be resident in RAM when the
   call returns successfully; the pages are guaranteed to stay in RAM
   until later unlocked.

According to the description in the manual, the two testcases are equivalent.

why the first testcase does not invoke OOM killer?
does the mmap with MAP_LOCKED flag will not immediately allocate physical 
memory?


Best Regards
Wang Long

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irq: irq-hip04: initialize hip04_cpu_map to 0xffff

2015-01-03 Thread long.wanglong

On 2014/12/11 19:19, Haojian Zhuang wrote:
> On 11 December 2014 at 19:03, Wang Long  wrote:
>> HiP04 GIC extends to support 16 cores, so we should
>> initialize the hip04_cpu_map to 0x.
>>
>> Signed-off-by: Wang Long 
>> ---
>>  drivers/irqchip/irq-hip04.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c
>> index 9c8f8335..8eee46b 100644
>> --- a/drivers/irqchip/irq-hip04.c
>> +++ b/drivers/irqchip/irq-hip04.c
>> @@ -382,7 +382,7 @@ hip04_of_init(struct device_node *node, struct 
>> device_node *parent)
>>  * It will be refined as each CPU probes its ID.
>>  */
>> for (i = 0; i < NR_HIP04_CPU_IF; i++)
>> -   hip04_cpu_map[i] = 0xff;
>> +   hip04_cpu_map[i] = 0x;
>>
>> /*
>>  * Find out how many interrupts are supported.
>> --
>> 1.8.3.4
>>
> 
> Acked-by: Haojian Zhuang 
> 
> Best Regards
> Haojian
> 
> 

hi Thomas Gleixner, Jason Cooper

could you please help to apply this patch?

Best Regards
Wang Long


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irq: irq-hip04: initialize hip04_cpu_map to 0xffff

2015-01-03 Thread long.wanglong

On 2014/12/11 19:19, Haojian Zhuang wrote:
 On 11 December 2014 at 19:03, Wang Long long.wangl...@huawei.com wrote:
 HiP04 GIC extends to support 16 cores, so we should
 initialize the hip04_cpu_map to 0x.

 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  drivers/irqchip/irq-hip04.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c
 index 9c8f8335..8eee46b 100644
 --- a/drivers/irqchip/irq-hip04.c
 +++ b/drivers/irqchip/irq-hip04.c
 @@ -382,7 +382,7 @@ hip04_of_init(struct device_node *node, struct 
 device_node *parent)
  * It will be refined as each CPU probes its ID.
  */
 for (i = 0; i  NR_HIP04_CPU_IF; i++)
 -   hip04_cpu_map[i] = 0xff;
 +   hip04_cpu_map[i] = 0x;

 /*
  * Find out how many interrupts are supported.
 --
 1.8.3.4

 
 Acked-by: Haojian Zhuang haojian.zhu...@linaro.org
 
 Best Regards
 Haojian
 
 

hi Thomas Gleixner, Jason Cooper

could you please help to apply this patch?

Best Regards
Wang Long


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SMP BUG?] the return value of is_smp() is bug?

On 2014/9/1 18:26, Arnd Bergmann wrote:
> On Monday 01 September 2014 18:00:58 long.wanglong wrote:
>> On 2014/9/1 13:49, Wang Long wrote:
>>>
>>> Hi,all
>>>
>>> In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y 
>>> in .config file. the secondary core can not boot.
>>>
>>> when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
>>> the secondary core can boot.
>>>
>>> But this does not happen in kernel 3.10 lts kernel, Whether the 
>>> CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
>>>
>>> Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel 
>>> 3.17-rc2 ? 
>>>
>>>
>>
>> hi Arnd
>>
>> In above two cases, i also set  CONFIG_SMP = y. in addtion,
>> the CONFIG_SMP_ON_UP depends on CONFIG_SMP. when set
>> CONFIG_SMP_ON_UP = y, the value of CONFIG_SMP must be y.
> 
> I see.
> 
> I'm looking at the code more closely now:
> 
>>> config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
>>> command:# qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel 
>>> arch/arm/boot/zImage -nographic
>>> The output:
>>>
>>> ..
>>> is_smp() return false;
> 
> This test basically checks whether the __fixup_smp_on_up code was
> run or not. This has changed in bc41b8724f24 "ARM: 7846/1: Update
> SMP_ON_UP code to detect A9MPCore with 1 CPU devices", in order
> to support a quirk in the Aegis platform. Can you try reverting
> that commit?
> 
>   Arnd
> 
> .
> 


Hi Arnd

When i revert the commit bc41b8724f24, the secondary core can boot.
The problem is that qemu doesn't provide emulation of the SCU base
address register. When reading the SCU base, qemu just return 0.

In the real hardware, there is no this problem.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SMP BUG?] the return value of is_smp() is bug?

On 2014/9/1 18:19, Russell King - ARM Linux wrote:
> Firstly, do not send multiple copies of your message to mailing lists,
> certainly not within the three hours that you sent your three copies.
> If one of the addresses you sent the message to bounces, then it is
> *only* that one recipient who doesn't get your message, everyone else
> receives a copy.  So, there's now three copies of your message in the
> list archives, and people could end up replying to different messages.
> 
> On Mon, Sep 01, 2014 at 07:35:34PM +0800, Wang Long wrote:
>> Hi,all
>>
>> In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y 
>> in .config file. the secondary core can not boot.
>>
>> when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
>> the secondary core can boot.
>>
>> But this does not happen in kernel 3.10 lts kernel, Whether the 
>> CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
>>
>> Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel 
>> 3.17-rc2 ? 
> 
> I think the answer is neither, because when the kernel is run on /real/
> hardware:
> 
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot=2514
> 
> it boots fine, bringing up all four CPUs.
> 
>> config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
>> command:# qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel 
>> arch/arm/boot/zImage -nographic
> 
> I've no idea how qemu works here, but if the CPU doesn't indicate that
> it's a SMP capable CPU, we will disable SMP extensions.
> 
>> The output:
>>
>> ..
>> is_smp() return false;
>> CPU: Testing write buffer coherency: ok
>> missing device node for CPU 0
>> CPU0: thread -1, cpu 0, socket 0, mpidr 8000
>> Setting up static identity map for 0x604643d8 - 0x60464430
>> Brought up 1 CPUs
>> SMP: Total of 1 processors activated.
>> CPU: All CPU(s) started in SVC mode.
>> ...
> 
> You have decided that you'll edit the kernel messages, removing at least
> some of the information that could be relevant to the issue.  Please,
> only cut kernel messages when you are absolutely certain that they are
> not relevant to the problem you're reporting.
> 
> However, I don't think it would help much - I suspect that qemu doesn't
> provide emulation of the SCU base address register, and that's what your
> problem is.  qemu needs to be fixed in that regard.
> 

Hi,Russell King

Thank you for your reply. I will not send multiple copies of message to mailing 
lists.
The problem is that qemu doesn't provide emulation of the SCU base address 
register.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SMP BUG?] the return value of is_smp() is bug?

On 2014/9/1 18:19, Russell King - ARM Linux wrote:
 Firstly, do not send multiple copies of your message to mailing lists,
 certainly not within the three hours that you sent your three copies.
 If one of the addresses you sent the message to bounces, then it is
 *only* that one recipient who doesn't get your message, everyone else
 receives a copy.  So, there's now three copies of your message in the
 list archives, and people could end up replying to different messages.
 
 On Mon, Sep 01, 2014 at 07:35:34PM +0800, Wang Long wrote:
 Hi,all

 In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y 
 in .config file. the secondary core can not boot.

 when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
 the secondary core can boot.

 But this does not happen in kernel 3.10 lts kernel, Whether the 
 CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.

 Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel 
 3.17-rc2 ? 
 
 I think the answer is neither, because when the kernel is run on /real/
 hardware:
 
 http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=2514
 
 it boots fine, bringing up all four CPUs.
 
 config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
 command:# qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel 
 arch/arm/boot/zImage -nographic
 
 I've no idea how qemu works here, but if the CPU doesn't indicate that
 it's a SMP capable CPU, we will disable SMP extensions.
 
 The output:

 ..
 is_smp() return false;
 CPU: Testing write buffer coherency: ok
 missing device node for CPU 0
 CPU0: thread -1, cpu 0, socket 0, mpidr 8000
 Setting up static identity map for 0x604643d8 - 0x60464430
 Brought up 1 CPUs
 SMP: Total of 1 processors activated.
 CPU: All CPU(s) started in SVC mode.
 ...
 
 You have decided that you'll edit the kernel messages, removing at least
 some of the information that could be relevant to the issue.  Please,
 only cut kernel messages when you are absolutely certain that they are
 not relevant to the problem you're reporting.
 
 However, I don't think it would help much - I suspect that qemu doesn't
 provide emulation of the SCU base address register, and that's what your
 problem is.  qemu needs to be fixed in that regard.
 

Hi,Russell King

Thank you for your reply. I will not send multiple copies of message to mailing 
lists.
The problem is that qemu doesn't provide emulation of the SCU base address 
register.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SMP BUG?] the return value of is_smp() is bug?