Re: WARNING in task_participate_group_stop

On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov wrote: > On 10/30, Dmitry Vyukov wrote: >> >> On Mon, Oct 30, 2017 at 10:12 PM, syzbot >> >> wrote: >> > Hello, >> > >> > syzkaller hit the following crash on

Re: WARNING in task_participate_group_stop

On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov wrote: > On 10/30, Dmitry Vyukov wrote: >> >> On Mon, Oct 30, 2017 at 10:12 PM, syzbot >> >> wrote: >> > Hello, >> > >> > syzkaller hit the following crash on >> > d95e159cd1da1ed4dbf76bf203e8ffaf231395e4 >> >

[PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

The meaning of perf record's "overwrite" option and many "overwrite" in source code are not clear. In perf's code, the 'overwrite' has 2 meanings: 1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument). 2. Set evsel's "backward" attribute (in apply_config_terms). perf record doesn't use

[PATCH 0/2] perf record: Fix --overwrite and clarify concepts

Kan reports that 'perf record --overwrite' not working as it should be. Patch 1/2 fix a bug, map backward events to readonly ring buffer so kernel can overwrite that ring buffer. Patch 2/2 clarify concepts of 'overwrite' and 'backward' in the source code by introducing the concept of

[PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

The meaning of perf record's "overwrite" option and many "overwrite" in source code are not clear. In perf's code, the 'overwrite' has 2 meanings: 1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument). 2. Set evsel's "backward" attribute (in apply_config_terms). perf record doesn't use

[PATCH 0/2] perf record: Fix --overwrite and clarify concepts

Kan reports that 'perf record --overwrite' not working as it should be. Patch 1/2 fix a bug, map backward events to readonly ring buffer so kernel can overwrite that ring buffer. Patch 2/2 clarify concepts of 'overwrite' and 'backward' in the source code by introducing the concept of

[PATCH 1/2] perf mmap: Fix perf backward recording

perf record backward recording doesn't work as we expected: it never overwrite when ring buffer full. Test: (Run a busy printing python task background like this: while True: print 123 send SIGUSR2 to perf to capture snapshot.) # ./perf record --overwrite -e raw_syscalls:sys_enter -e

[PATCH 1/2] perf mmap: Fix perf backward recording

perf record backward recording doesn't work as we expected: it never overwrite when ring buffer full. Test: (Run a busy printing python task background like this: while True: print 123 send SIGUSR2 to perf to capture snapshot.) # ./perf record --overwrite -e raw_syscalls:sys_enter -e

linux-next: manual merge of the tip tree with the powerpc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/powerpc/mm/numa.c between commit: cee5405da402 ("powerpc/hotplug: Improve responsiveness of hotplug change") from the powerpc tree and commit: df7e828c1b69 ("timer: Remove init_timer_deferrable() in favor of

linux-next: manual merge of the tip tree with the powerpc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/powerpc/mm/numa.c between commit: cee5405da402 ("powerpc/hotplug: Improve responsiveness of hotplug change") from the powerpc tree and commit: df7e828c1b69 ("timer: Remove init_timer_deferrable() in favor of

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/arm64/Kconfig between commit: 396a5d4a5c32 ("arm64: Unconditionally support {ARCH_}HAVE_NMI{_SAFE_CMPXCHG}") from the arm64 tree and commit: 087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: arch/arm64/Kconfig between commit: 396a5d4a5c32 ("arm64: Unconditionally support {ARCH_}HAVE_NMI{_SAFE_CMPXCHG}") from the arm64 tree and commit: 087133ac9076 ("locking/qrwlock, arm64: Move rwlock implementation over

Re: [PATCH 1/2] mm:swap: clean up swap readahead

Hi Huang, On Wed, Nov 01, 2017 at 01:41:00PM +0800, Huang, Ying wrote: > Hi, Minchan, > > Minchan Kim writes: > > > When I see recent change of swap readahead, I am very unhappy > > about current code structure which diverges two swap readahead > > algorithm in

Re: [PATCH 1/2] mm:swap: clean up swap readahead

Hi Huang, On Wed, Nov 01, 2017 at 01:41:00PM +0800, Huang, Ying wrote: > Hi, Minchan, > > Minchan Kim writes: > > > When I see recent change of swap readahead, I am very unhappy > > about current code structure which diverges two swap readahead > > algorithm in do_swap_page. This patch is to

Re: [PATCH 1/2] mm:swap: clean up swap readahead

Hi, Minchan, Minchan Kim writes: > When I see recent change of swap readahead, I am very unhappy > about current code structure which diverges two swap readahead > algorithm in do_swap_page. This patch is to clean it up. > > Main motivation is that fault handler doesn't need

Re: [PATCH 1/2] mm:swap: clean up swap readahead

Hi, Minchan, Minchan Kim writes: > When I see recent change of swap readahead, I am very unhappy > about current code structure which diverges two swap readahead > algorithm in do_swap_page. This patch is to clean it up. > > Main motivation is that fault handler doesn't need to be aware of >

[RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

It is common for services to be stateless around their main event loop. If a process passes the EPOLL_KILLME flag to epoll_wait5() then it signals to the kernel that epoll_wait5() may not complete, and the kernel may send SIGKILL if resources get tight. See my systemd patch:

[RFC] EPOLL_KILLME: New flag to epoll_wait() that subscribes process to death row (new syscall)

It is common for services to be stateless around their main event loop. If a process passes the EPOLL_KILLME flag to epoll_wait5() then it signals to the kernel that epoll_wait5() may not complete, and the kernel may send SIGKILL if resources get tight. See my systemd patch:

[PATCH 0/2] swap readahead clean up

This patchset cleans up recent added vma-based readahead code via unifying cluster-based readahead. Minchan Kim (2): mm:swap: clean up swap readahead mm:swap: unify cluster-based and vma-based swap readahead include/linux/swap.h | 32 +++ mm/memory.c | 24 +++

[PATCH 1/2] mm:swap: clean up swap readahead

When I see recent change of swap readahead, I am very unhappy about current code structure which diverges two swap readahead algorithm in do_swap_page. This patch is to clean it up. Main motivation is that fault handler doesn't need to be aware of readahead algorithms but just should call

[PATCH 0/2] swap readahead clean up

This patchset cleans up recent added vma-based readahead code via unifying cluster-based readahead. Minchan Kim (2): mm:swap: clean up swap readahead mm:swap: unify cluster-based and vma-based swap readahead include/linux/swap.h | 32 +++ mm/memory.c | 24 +++

[PATCH 1/2] mm:swap: clean up swap readahead

When I see recent change of swap readahead, I am very unhappy about current code structure which diverges two swap readahead algorithm in do_swap_page. This patch is to clean it up. Main motivation is that fault handler doesn't need to be aware of readahead algorithms but just should call

[PATCH 2/2] mm:swap: unify cluster-based and vma-based swap readahead

This patch makes do_swap_page no need to be aware of two different swap readahead algorithm. Just unify cluster-based and vma-based readahead function call. Signed-off-by: Minchan Kim --- include/linux/swap.h | 17 - mm/memory.c | 11 ---

[PATCH 2/2] mm:swap: unify cluster-based and vma-based swap readahead

This patch makes do_swap_page no need to be aware of two different swap readahead algorithm. Just unify cluster-based and vma-based readahead function call. Signed-off-by: Minchan Kim --- include/linux/swap.h | 17 - mm/memory.c | 11 --- mm/shmem.c |

Re: xfs: list corruption in xfs_setup_inode()

On Tue, Oct 31, 2017 at 09:43:03PM -0700, Cong Wang wrote: > On Tue, Oct 31, 2017 at 8:05 PM, Dave Chinner wrote: > > On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote: > >> >> Please let me know if I can provide any other information. > >> > > >> > How do you

Re: xfs: list corruption in xfs_setup_inode()

On Tue, Oct 31, 2017 at 09:43:03PM -0700, Cong Wang wrote: > On Tue, Oct 31, 2017 at 8:05 PM, Dave Chinner wrote: > > On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote: > >> >> Please let me know if I can provide any other information. > >> > > >> > How do you reproduce the problem? > >>

Re: [PATCH 1/2] bpf: add a bpf_override_function helper

On 10/31/17 8:45 AM, Josef Bacik wrote: From: Josef Bacik Error injection is sloppy and very ad-hoc. BPF could fill this niche perfectly with it's kprobe functionality. We could make sure errors are only triggered in specific call chains that we care about with very specific

Re: [PATCH 1/2] bpf: add a bpf_override_function helper

On 10/31/17 8:45 AM, Josef Bacik wrote: From: Josef Bacik Error injection is sloppy and very ad-hoc. BPF could fill this niche perfectly with it's kprobe functionality. We could make sure errors are only triggered in specific call chains that we care about with very specific situations.

Re: xfs: list corruption in xfs_setup_inode()

On Tue, Oct 31, 2017 at 8:05 PM, Dave Chinner wrote: > On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote: >> On Mon, Oct 30, 2017 at 5:33 PM, Dave Chinner wrote: >> > On Mon, Oct 30, 2017 at 02:55:43PM -0700, Cong Wang wrote: >> >> Hello, >> >>

Re: xfs: list corruption in xfs_setup_inode()

On Tue, Oct 31, 2017 at 8:05 PM, Dave Chinner wrote: > On Tue, Oct 31, 2017 at 06:51:08PM -0700, Cong Wang wrote: >> On Mon, Oct 30, 2017 at 5:33 PM, Dave Chinner wrote: >> > On Mon, Oct 30, 2017 at 02:55:43PM -0700, Cong Wang wrote: >> >> Hello, >> >> >> >> We triggered a list corruption

Re: [PATCH v2] sched/sysctl: Fix attributes of some extern declarations

> El Tue, Oct 30, 2017 at 10:57:58AM +0100 Ingo Molnar ha dit: >> So I hate this change, because it pointlessly duplicates an attribute that >> should >> only matter at the definition site. > > It's certainly not ideal, and then again essentially the same is done > in kernel/sched/sched.h, just

Re: [PATCH v2] sched/sysctl: Fix attributes of some extern declarations

> El Tue, Oct 30, 2017 at 10:57:58AM +0100 Ingo Molnar ha dit: >> So I hate this change, because it pointlessly duplicates an attribute that >> should >> only matter at the definition site. > > It's certainly not ideal, and then again essentially the same is done > in kernel/sched/sched.h, just

[PATCH V10 1/2] kasan: use %pK to print addresses instead of %p

In preparation for hashing addresses printed using %p. We need the actual address for error reporting in kasan. Use %pK instead of %p to print addresses. Signed-off-by: Tobin C. Harding --- mm/kasan/report.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff

[PATCH V10 2/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH V10 1/2] kasan: use %pK to print addresses instead of %p

In preparation for hashing addresses printed using %p. We need the actual address for error reporting in kasan. Use %pK instead of %p to print addresses. Signed-off-by: Tobin C. Harding --- mm/kasan/report.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH V10 2/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH V10 0/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH V10 0/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

Re: [PATCH] at24: support eeproms that do not roll over page reads.

Hi Sven, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc7] [cannot apply to next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] at24: support eeproms that do not roll over page reads.

Hi Sven, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc7] [cannot apply to next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] selftests/ftrace: Introduce exit_pass and exit_fail

On Tue, 31 Oct 2017 17:44:32 -0400 Steven Rostedt wrote: > On Tue, 31 Oct 2017 23:51:42 +0900 > Masami Hiramatsu wrote: > > > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > >

Re: [PATCH] selftests/ftrace: Introduce exit_pass and exit_fail

On Tue, 31 Oct 2017 17:44:32 -0400 Steven Rostedt wrote: > On Tue, 31 Oct 2017 23:51:42 +0900 > Masami Hiramatsu wrote: > > > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > > b/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > > index

Re: [PATCH] [irq] Fix boot failure when irqaffinity is passed.

On Tue, Oct 31, 2017 at 5:29 PM, Ingo Molnar wrote: > > > Not applied, because this patch causes the following build warning: > > kernel/irq/irqdesc.c:43:6: warning: the address of ‘irq_default_affinity’ > will always evaluate as ‘true’ [-Waddress] > Ah, sorry I didn't look

Re: [PATCH] [irq] Fix boot failure when irqaffinity is passed.

On Tue, Oct 31, 2017 at 5:29 PM, Ingo Molnar wrote: > > > Not applied, because this patch causes the following build warning: > > kernel/irq/irqdesc.c:43:6: warning: the address of ‘irq_default_affinity’ > will always evaluate as ‘true’ [-Waddress] > Ah, sorry I didn't look into the build log.

Re: [PATCH] at24: support eeproms that do not roll over page reads.

Hi Sven, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc7] [cannot apply to next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] at24: support eeproms that do not roll over page reads.

Hi Sven, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.14-rc7] [cannot apply to next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: linux-next: manual merge of the net-next tree with the net tree

On Tue, Oct 31, 2017 at 5:58 PM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > net/sched/cls_api.c > > between commit: > > 822e86d997e4 ("net_sched: remove tcf_block_put_deferred()") > > from the net tree and

Re: linux-next: manual merge of the net-next tree with the net tree

On Tue, Oct 31, 2017 at 5:58 PM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > net/sched/cls_api.c > > between commit: > > 822e86d997e4 ("net_sched: remove tcf_block_put_deferred()") > > from the net tree and commit: > >

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

On 2017/10/31 23:38, James Morse wrote: > CC'd people I've seen posting CPER log fragments, could you give this a > test on your platforms? Thanks for the fixing, not found obviously issue.

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

On 2017/10/31 23:38, James Morse wrote: > CC'd people I've seen posting CPER log fragments, could you give this a > test on your platforms? Thanks for the fixing, not found obviously issue.

[PATCH] irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1)

When the irqaffinity= kernel parameter is passed in a CPUMASK_OFFSTACK=y kernel, it fails to boot, because zalloc_cpumask_var() cannot be used before initializing the slab allocator to allocate a cpumask. So, use alloc_bootmem_cpumask_var() instead. Also do some cleanups while at it: in

[PATCH] irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1)

When the irqaffinity= kernel parameter is passed in a CPUMASK_OFFSTACK=y kernel, it fails to boot, because zalloc_cpumask_var() cannot be used before initializing the slab allocator to allocate a cpumask. So, use alloc_bootmem_cpumask_var() instead. Also do some cleanups while at it: in

linux-next: build warning after merge of the sound-asoc tree

Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: sound/soc/stm/stm32_sai_sub.c: In function 'stm32_sai_hw_params': sound/soc/stm/stm32_sai_sub.c:485:7: warning: 'cr1' may be used uninitialized in this function

linux-next: build warning after merge of the sound-asoc tree

Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: sound/soc/stm/stm32_sai_sub.c: In function 'stm32_sai_hw_params': sound/soc/stm/stm32_sai_sub.c:485:7: warning: 'cr1' may be used uninitialized in this function

[PATCH v3 1/2] gpio: gpiolib: Generalise state persistence beyond sleep

General support for state persistence is added to gpiolib with the introduction of a new pinconf parameter to propagate the request to hardware. The existing persistence support for sleep is adapted to include hardware support if the GPIO driver provides it. Persistence continues to be enabled by

[PATCH v3 2/2] gpio: aspeed: Add support for reset tolerance

Use the new pinconf parameter for state persistence to expose the associated capability of the Aspeed GPIO controller. Signed-off-by: Andrew Jeffery --- drivers/gpio/gpio-aspeed.c | 39 +-- 1 file changed, 37 insertions(+), 2 deletions(-)

[PATCH v3 0/2] gpio: Generalise state persistence

Hello, This series provides an API to configure general GPIO state persistence in gpiolib. Previously, only sleep persistence was considered, but controllers like one found in Aspeed BMCs also support persistence of state across controller resets. There is some prior discussion on v1[1] and the

[PATCH v3 1/2] gpio: gpiolib: Generalise state persistence beyond sleep

General support for state persistence is added to gpiolib with the introduction of a new pinconf parameter to propagate the request to hardware. The existing persistence support for sleep is adapted to include hardware support if the GPIO driver provides it. Persistence continues to be enabled by

[PATCH v3 2/2] gpio: aspeed: Add support for reset tolerance

Use the new pinconf parameter for state persistence to expose the associated capability of the Aspeed GPIO controller. Signed-off-by: Andrew Jeffery --- drivers/gpio/gpio-aspeed.c | 39 +-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git

[PATCH v3 0/2] gpio: Generalise state persistence

Hello, This series provides an API to configure general GPIO state persistence in gpiolib. Previously, only sleep persistence was considered, but controllers like one found in Aspeed BMCs also support persistence of state across controller resets. There is some prior discussion on v1[1] and the

linux-next: manual merge of the sound-asoc tree with the drm tree

Hi all, Today's linux-next merge of the sound-asoc tree got a conflict in: drivers/gpu/drm/amd/include/amd_shared.h between commit: cfa289fd4986 ("drm/amdgpu: rename amdgpu_dpm_funcs to amd_pm_funcs") from the drm tree and commit: f674bd281460 ("drm/amdgpu Moving amdgpu asic types to a

linux-next: manual merge of the sound-asoc tree with the drm tree

Hi all, Today's linux-next merge of the sound-asoc tree got a conflict in: drivers/gpu/drm/amd/include/amd_shared.h between commit: cfa289fd4986 ("drm/amdgpu: rename amdgpu_dpm_funcs to amd_pm_funcs") from the drm tree and commit: f674bd281460 ("drm/amdgpu Moving amdgpu asic types to a

[PATCH 2/2] Documentation: fsl: dspi: Add a compatible string for ls1088a DSPI

From: Hou Zhiqiang Add a new compatible string "fsl,ls1088a-dspi". Signed-off-by: Hou Zhiqiang --- Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 1/2] arm64: dts: ls1088a: add DT nodes for DSPI support

From: Hou Zhiqiang Signed-off-by: Hou Zhiqiang --- arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts | 28 +++ arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 13 +++ 2 files changed, 41 insertions(+) diff --git

[PATCH 2/2] Documentation: fsl: dspi: Add a compatible string for ls1088a DSPI

From: Hou Zhiqiang Add a new compatible string "fsl,ls1088a-dspi". Signed-off-by: Hou Zhiqiang --- Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt

[PATCH 1/2] arm64: dts: ls1088a: add DT nodes for DSPI support

From: Hou Zhiqiang Signed-off-by: Hou Zhiqiang --- arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts | 28 +++ arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 13 +++ 2 files changed, 41 insertions(+) diff --git

[PATCH 0/2] arm64: dts: Add ls1088a DSPI device tree nodes

From: Hou Zhiqiang LS1088A reuse LS2085A DSPI driver, this patchset just adds device tree nodes and adds compatible entry to documentation. Hou Zhiqiang (2): arm64: dts: ls1088a: add DT nodes for DSPI support Documentation: fsl: dspi: Add a compatible string for

[PATCH 0/2] arm64: dts: Add ls1088a DSPI device tree nodes

From: Hou Zhiqiang LS1088A reuse LS2085A DSPI driver, this patchset just adds device tree nodes and adds compatible entry to documentation. Hou Zhiqiang (2): arm64: dts: ls1088a: add DT nodes for DSPI support Documentation: fsl: dspi: Add a compatible string for ls1088a DSPI

linux-next: build warning after merge of the drm-msm tree

Hi Rob, After merging the drm-msm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/drm/drm_mm.h:49:0, from include/drm/drmP.h:73, from drivers/gpu/drm/msm/msm_drv.h:37, from

linux-next: build warning after merge of the drm-msm tree

Hi Rob, After merging the drm-msm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/drm/drm_mm.h:49:0, from include/drm/drmP.h:73, from drivers/gpu/drm/msm/msm_drv.h:37, from

linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: include/drm/drmP.h between commit: e7646f84ad4f ("drm: Add new LEASE debug level") from the drm tree and commit: 02c9656b2f0d ("drm: Move debug macros out of drmP.h") from the drm-misc tree. I fixed it up (I

linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: include/drm/drmP.h between commit: e7646f84ad4f ("drm: Add new LEASE debug level") from the drm tree and commit: 02c9656b2f0d ("drm: Move debug macros out of drmP.h") from the drm-misc tree. I fixed it up (I

[PATCH v3] tracing: Allocate mask_str buffer dynamically

From: Changbin Du The default NR_CPUS can be very large, but actual possible nr_cpu_ids usually is very small. For my x86 distribution, the NR_CPUS is 8192 and nr_cpu_ids is 4. About 2 pages are wasted. Most machines don't have so many CPUs, so define a array with NR_CPUS

[PATCH v3] tracing: Allocate mask_str buffer dynamically

From: Changbin Du The default NR_CPUS can be very large, but actual possible nr_cpu_ids usually is very small. For my x86 distribution, the NR_CPUS is 8192 and nr_cpu_ids is 4. About 2 pages are wasted. Most machines don't have so many CPUs, so define a array with NR_CPUS just wastes memory. So

Re: [PATCH] atm: iphase: Fix space before '[' error.

From: Arvind Yadav Date: Mon, 30 Oct 2017 21:22:03 +0530 > Fix checkpatch.pl error: > ERROR: space prohibited before open square bracket '['. > > Signed-off-by: Arvind Yadav Applied.

Re: [PATCH] atm: iphase: Fix space before '[' error.

From: Arvind Yadav Date: Mon, 30 Oct 2017 21:22:03 +0530 > Fix checkpatch.pl error: > ERROR: space prohibited before open square bracket '['. > > Signed-off-by: Arvind Yadav Applied.

Re: [PATCH 2/3] thermal: int340x: processor_thermal: Add Coffee Lake support

On Thu, 2017-10-19 at 14:51 -0700, Srinivas Pandruvada wrote: > Add new PCI id for Coffee lake processor thermal device. > > Signed-off-by: Srinivas Pandruvada om> > --- >  drivers/thermal/int340x_thermal/processor_thermal_device.c | 1 + >  1 file changed, 1

Re: [PATCH 2/3] thermal: int340x: processor_thermal: Add Coffee Lake support

On Thu, 2017-10-19 at 14:51 -0700, Srinivas Pandruvada wrote: > Add new PCI id for Coffee lake processor thermal device. > > Signed-off-by: Srinivas Pandruvada om> > --- >  drivers/thermal/int340x_thermal/processor_thermal_device.c | 1 + >  1 file changed, 1 insertion(+) > > diff --git >

Re: [PATCH net-next 0/6] net: ppv2: various improvements

From: Antoine Tenart Date: Mon, 30 Oct 2017 11:23:27 +0100 > This series includes various patches improving the Marvell PPv2 driver. > I send them as a series to avoid any possible merge conflict. > > - Patches 1 and 2 improve the initializing of the Tx and Rx

Re: [PATCH net-next 0/6] net: ppv2: various improvements

From: Antoine Tenart Date: Mon, 30 Oct 2017 11:23:27 +0100 > This series includes various patches improving the Marvell PPv2 driver. > I send them as a series to avoid any possible merge conflict. > > - Patches 1 and 2 improve the initializing of the Tx and Rx FIFO. > - Patch 3 initialize the

Re: Kernel crash in free_pipe_info()

On Mon, Oct 30, 2017 at 7:08 PM, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 6:19 PM, Cong Wang wrote: >> >> 1. The faulty addresses are all near 0001, with one exception >> of null (which is the most recent one) > > Well,

Re: Kernel crash in free_pipe_info()

On Mon, Oct 30, 2017 at 7:08 PM, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 6:19 PM, Cong Wang wrote: >> >> 1. The faulty addresses are all near 0001, with one exception >> of null (which is the most recent one) > > Well, they're at 8(%rax), except for that last case. > > And in

Re: [PATCH] x86, build: Improve the isolinux searching of isoimage generation

2017-10-31 18:39 GMT+09:00 Ingo Molnar : > > * changbin...@intel.com wrote: > >> From: Changbin Du >> >> Recently I failed to build isoimage target, because the path of isolinux.bin >> changed to /usr/xxx/ISOLINUX/isolinux.bin, as

Re: [PATCH] x86, build: Improve the isolinux searching of isoimage generation

2017-10-31 18:39 GMT+09:00 Ingo Molnar : > > * changbin...@intel.com wrote: > >> From: Changbin Du >> >> Recently I failed to build isoimage target, because the path of isolinux.bin >> changed to /usr/xxx/ISOLINUX/isolinux.bin, as well as ldlinux.c32 which >> changed to

Re: [PATCH] net: hns: set correct return value

From: Pan Bian Date: Mon, 30 Oct 2017 16:50:01 +0800 > The function of_parse_phandle() returns a NULL pointer if it cannot > resolve a phandle property to a device_node pointer. In function > hns_nic_dev_probe(), its return value is passed to PTR_ERR to extract > the error

Re: [PATCH] net: hns: set correct return value

From: Pan Bian Date: Mon, 30 Oct 2017 16:50:01 +0800 > The function of_parse_phandle() returns a NULL pointer if it cannot > resolve a phandle property to a device_node pointer. In function > hns_nic_dev_probe(), its return value is passed to PTR_ERR to extract > the error code. However, in this

linux-next: build warnings after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/gpu/drm/vc4/vc4_bo.c: In function 'vc4_bo_stats_debugfs': drivers/gpu/drm/vc4/vc4_bo.c:91:17: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t

linux-next: build warnings after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/gpu/drm/vc4/vc4_bo.c: In function 'vc4_bo_stats_debugfs': drivers/gpu/drm/vc4/vc4_bo.c:91:17: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t

Re: net: lapbether: fix double free

From: Pan Bian Date: Sun, 29 Oct 2017 21:57:22 +0800 > The function netdev_priv() returns the private data of the device. The > memory to store the private data is allocated in alloc_netdev() and is > released in netdev_free(). Calling kfree() on the return value of >

Re: net: lapbether: fix double free

From: Pan Bian Date: Sun, 29 Oct 2017 21:57:22 +0800 > The function netdev_priv() returns the private data of the device. The > memory to store the private data is allocated in alloc_netdev() and is > released in netdev_free(). Calling kfree() on the return value of > netdev_priv() after

Re: [PATCH] mkiss: remove redundant assignment of len to ax->mtu

From: Colin King Date: Sun, 29 Oct 2017 13:30:25 + > From: Colin Ian King > > Variable len is being assigned a value that is never read, > hence the assignment is redundant and can be removed. Cleans > up clang warning: > >

Re: [PATCH] mkiss: remove redundant assignment of len to ax->mtu

From: Colin King Date: Sun, 29 Oct 2017 13:30:25 + > From: Colin Ian King > > Variable len is being assigned a value that is never read, > hence the assignment is redundant and can be removed. Cleans > up clang warning: > > drivers/net/hamradio/mkiss.c:443:3: warning: Value stored to >

Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

Hi Geert, Vinod Geert, thank you for your report, Vinod, thank you for your quick help. > > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB > > > instead of TCR for residue") in slave-dma/next, and breaks serial console > > > input on koelsch (shmobile_defconfig) and

Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

Hi Geert, Vinod Geert, thank you for your report, Vinod, thank you for your quick help. > > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB > > > instead of TCR for residue") in slave-dma/next, and breaks serial console > > > input on koelsch (shmobile_defconfig) and

Re: [PATCH] net: decnet: dn_nsp_out: use swap macro in dn_mk_ack_header

From: "Gustavo A. R. Silva" Date: Sat, 28 Oct 2017 15:39:48 -0500 > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A.

Re: [PATCH] net: decnet: dn_nsp_out: use swap macro in dn_mk_ack_header

From: "Gustavo A. R. Silva" Date: Sat, 28 Oct 2017 15:39:48 -0500 > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] net: dccp: ccids: lib: packet_history: use swap macro in tfrc_rx_hist_swap

From: "Gustavo A. R. Silva" Date: Sat, 28 Oct 2017 15:48:47 -0500 > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A.

Re: [PATCH] net: dccp: ccids: lib: packet_history: use swap macro in tfrc_rx_hist_swap

From: "Gustavo A. R. Silva" Date: Sat, 28 Oct 2017 15:48:47 -0500 > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] net: decnet: dn_nsp_in: use swap macro in dn_nsp_rx_packet

From: "Gustavo A. R. Silva" Date: Sat, 28 Oct 2017 14:38:45 -0500 > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A.

Re: [PATCH] net: decnet: dn_nsp_in: use swap macro in dn_nsp_rx_packet

From: "Gustavo A. R. Silva" Date: Sat, 28 Oct 2017 14:38:45 -0500 > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Applied.

  1   2   3   4   5   6   7   8   9   10   >