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

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 gene

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 kse

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 wr

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 buil

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 convers

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

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] 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/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 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,

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

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: [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 show_reg

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 withou

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 pr

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 m

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

[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 1024000KB(ulimit

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 drive

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

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

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 f

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

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

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

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

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

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.

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

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 expo

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

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

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

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 insertio

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 d

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