Request for stable 3.10.y inclusion: fix for CVE-2015-6937(rds)

Hi, Please backport upstream 4.3 commit 74e98eb085889b0d2d4908f59f6e00026063014f ("RDS: verify the underlying transport exists before creating a connection") to stable kernel 3.10. This patch fix CVE-2015-6937. Best Regards Wang Long -- To unsubscribe from this list: send the line

Request for stable 3.10.y inclusion: fix for CVE-2015-6937(rds)

Hi, Please backport upstream 4.3 commit 74e98eb085889b0d2d4908f59f6e00026063014f ("RDS: verify the underlying transport exists before creating a connection") to stable kernel 3.10. This patch fix CVE-2015-6937. Best Regards Wang Long -- To unsubscribe from this list: send the line

Re: [PATCH] kselftest: add cleankselftest rule

On 2015/10/2 22:18, Shuah Khan wrote: > On 09/30/2015 07:17 PM, Michael Ellerman wrote: >> On Wed, 2015-09-23 at 09:33 +, Wang Long wrote: >>> We use >>> >>> $make TARGETS="size timers" kselftest >>> >>> to build and run selftests. but there is no rule >>> for us to clean the kselftest

Re: [PATCH] kselftest: add cleankselftest rule

On 2015/10/2 22:18, Shuah Khan wrote: > On 09/30/2015 07:17 PM, Michael Ellerman wrote: >> On Wed, 2015-09-23 at 09:33 +, Wang Long wrote: >>> We use >>> >>> $make TARGETS="size timers" kselftest >>> >>> to build and run selftests. but there is no rule >>> for us to clean the kselftest

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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,

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

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. >>> &g

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

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

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

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

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

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,

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

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 > [] >> @@

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

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 @@

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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().

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

Re: [RFC] kernel random segmentation fault?

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

Re: [RFC] kernel random segmentation fault?

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

[RFC] kernel random segmentation fault?

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

[RFC] kernel random segmentation fault?

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

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

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

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

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; >>>

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;

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:

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

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

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

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

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

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

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

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

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

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 ---

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 > --- >

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 > >

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

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

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

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? > >

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

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

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 > >

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,

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

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

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

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

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

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

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,

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

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

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

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

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 fo

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

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

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

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

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

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

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

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

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

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 |

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

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 |

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

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 |

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

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

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

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 |

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 >>

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

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

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

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

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. > >

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

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