[PATCH 00/12] Major code reorganization to make all i2c transfers working

The current driver is failing in following test case 1. Handling of failure cases is not working in long run for BAM mode. It generates error message “bam-dma-engine 7884000.dma: Cannot free busy channel” sometimes. 2. Following I2C transfers are failing a. Single transfer with multiple

[PATCH 02/12] i2c: qup: minor code reorganization for use_dma

1. Assigns use_dma in qup_dev structure itself which will help in subsequent patches to determine the mode in IRQ handler. 2. Does minor code reorganization for loops to reduce the unnecessary comparison and assignment. Signed-off-by: Abhishek Sahu ---

[PATCH 01/12] i2c: qup: fixed releasing dma without flush operation completion

The QUP BSLP BAM generates the following error sometimes if the current I2C DMA transfer fails and the flush operation has been scheduled “bam-dma-engine 7884000.dma: Cannot free busy channel” If any I2C error comes during BAM DMA transfer, then the QUP I2C interrupt will be generated and

[PATCH 00/12] Major code reorganization to make all i2c transfers working

The current driver is failing in following test case 1. Handling of failure cases is not working in long run for BAM mode. It generates error message “bam-dma-engine 7884000.dma: Cannot free busy channel” sometimes. 2. Following I2C transfers are failing a. Single transfer with multiple

[PATCH 02/12] i2c: qup: minor code reorganization for use_dma

1. Assigns use_dma in qup_dev structure itself which will help in subsequent patches to determine the mode in IRQ handler. 2. Does minor code reorganization for loops to reduce the unnecessary comparison and assignment. Signed-off-by: Abhishek Sahu --- drivers/i2c/busses/i2c-qup.c | 19

[PATCH 01/12] i2c: qup: fixed releasing dma without flush operation completion

The QUP BSLP BAM generates the following error sometimes if the current I2C DMA transfer fails and the flush operation has been scheduled “bam-dma-engine 7884000.dma: Cannot free busy channel” If any I2C error comes during BAM DMA transfer, then the QUP I2C interrupt will be generated and

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

Hi Aaron, On Mon, Jan 08, 2018 at 10:41:41AM +0800, Aaron Ma wrote: > When size is negative, calling memset will make segment fault. > Declare the size as type u32 to keep memset safe. > > size in struct hid_report is unsigned, fix return type of > hid_report_len to u32. > > Cc:

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

Hi Aaron, On Mon, Jan 08, 2018 at 10:41:41AM +0800, Aaron Ma wrote: > When size is negative, calling memset will make segment fault. > Declare the size as type u32 to keep memset safe. > > size in struct hid_report is unsigned, fix return type of > hid_report_len to u32. > > Cc:

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote: > I just tested the 4.15 kernel and it is reporting that my old i486 > (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, > Spectre V1, and Spectre V2. > > I find this to be _unlikely_. This should be fixed in Linus' tree

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote: > I just tested the 4.15 kernel and it is reporting that my old i486 > (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, > Spectre V1, and Spectre V2. > > I find this to be _unlikely_. This should be fixed in Linus' tree

Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

于 2018年2月3日 GMT+08:00 上午6:13:01, Maxime Ripard 写到: >On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote: >> The V3s is just a differently packaged version of the V3 chip, which >has >> a MAC with the same capability with H3. The V3s just doesn't wire out >>

Re: Coccinelle: zalloc-simple: Checking consistency for SmPL rules

>> * Do we agree that a proper size determination is essential for every >> condition in the discussed SmPL rules together with forwarding >> this information? > > No. I don't mind a few false positives. Do you care to split SmPL rules by their confidence category in such an use case?

Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

于 2018年2月3日 GMT+08:00 上午6:13:01, Maxime Ripard 写到: >On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote: >> The V3s is just a differently packaged version of the V3 chip, which >has >> a MAC with the same capability with H3. The V3s just doesn't wire out >> the external MII/RMII/RGMII

Re: Coccinelle: zalloc-simple: Checking consistency for SmPL rules

>> * Do we agree that a proper size determination is essential for every >> condition in the discussed SmPL rules together with forwarding >> this information? > > No. I don't mind a few false positives. Do you care to split SmPL rules by their confidence category in such an use case?

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

于 2018年2月3日 GMT+08:00 下午2:00:33, Julian Calaby 写到: >Hi Icenowy, > >On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng wrote: >> The V3s is just a differently packaged version of the V3 chip, which >has >> a MAC with the same capability with H3. The V3s just

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

于 2018年2月3日 GMT+08:00 下午2:00:33, Julian Calaby 写到: >Hi Icenowy, > >On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng wrote: >> The V3s is just a differently packaged version of the V3 chip, which >has >> a MAC with the same capability with H3. The V3s just doesn't wire out >> the external

Re: clang warning: implicit conversion in intel_ddi.c:1481

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote: > On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote: > > On Fri, 02 Feb 2018, Greg KH wrote: > > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote: > > >> > > >> +Knut, Fengguang > > >> > > >> On

Re: clang warning: implicit conversion in intel_ddi.c:1481

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote: > On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote: > > On Fri, 02 Feb 2018, Greg KH wrote: > > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote: > > >> > > >> +Knut, Fengguang > > >> > > >> On Fri, 02 Feb 2018, Greg KH

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

Hi leilei.lin, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

Hi leilei.lin, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH] media: cx25821: prevent out-of-bounds read on array card

Hi Colin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [PATCH] media: cx25821: prevent out-of-bounds read on array card

Hi Colin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

Hi Icenowy, On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng wrote: > The V3s is just a differently packaged version of the V3 chip, which has > a MAC with the same capability with H3. The V3s just doesn't wire out > the external MII/RMII/RGMII bus. (V3 wired out it). > > Drop the

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

Hi Icenowy, On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng wrote: > The V3s is just a differently packaged version of the V3 chip, which has > a MAC with the same capability with H3. The V3s just doesn't wire out > the external MII/RMII/RGMII bus. (V3 wired out it). > > Drop the compatible string

Re: [PATCH AUTOSEL for 3.18 36/40] powerpc/xmon: Avoid tripping SMP hardlockup watchdog

On Tue, 30 Jan 2018 15:35:54 +1100 Michael Ellerman wrote: > alexander.le...@verizon.com writes: > > > On Thu, Dec 14, 2017 at 12:10:39AM +1100, Michael Ellerman wrote: > >>alexander.le...@verizon.com writes: > >> > >>> From: Nicholas Piggin > >>> >

Re: [PATCH AUTOSEL for 3.18 36/40] powerpc/xmon: Avoid tripping SMP hardlockup watchdog

On Tue, 30 Jan 2018 15:35:54 +1100 Michael Ellerman wrote: > alexander.le...@verizon.com writes: > > > On Thu, Dec 14, 2017 at 12:10:39AM +1100, Michael Ellerman wrote: > >>alexander.le...@verizon.com writes: > >> > >>> From: Nicholas Piggin > >>> > >>> [ Upstream commit

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

Hi leilei.lin, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH RESEND v3] perf/core: Fix installing cgroup event into cpu

Hi leilei.lin, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

[PATCH] audit: update bugtracker and source URIs

Since the Linux Audit project has transitioned completely over to github, update the MAINTAINERS file and the primary audit source file to reflect that reality. Signed-off-by: Richard Guy Briggs --- MAINTAINERS| 1 - kernel/audit.c | 3 ++- 2 files changed, 2 insertions(+),

[PATCH] audit: update bugtracker and source URIs

Since the Linux Audit project has transitioned completely over to github, update the MAINTAINERS file and the primary audit source file to reflect that reality. Signed-off-by: Richard Guy Briggs --- MAINTAINERS| 1 - kernel/audit.c | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-)

[BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

I just tested the 4.15 kernel and it is reporting that my old i486 (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, Spectre V1, and Spectre V2. I find this to be _unlikely_. /sys/devices/system/cpu/vulnerabilities/* reports the following: meltdown: "Vulnerable" spectre_v1:

[BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

I just tested the 4.15 kernel and it is reporting that my old i486 (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, Spectre V1, and Spectre V2. I find this to be _unlikely_. /sys/devices/system/cpu/vulnerabilities/* reports the following: meltdown: "Vulnerable" spectre_v1:

Re: [PATCH] net: mlx5: remove pointless memcpy

On 02/02/2018 12:26 PM, Arnd Bergmann wrote: > On Fri, Feb 2, 2018 at 8:06 PM, Jason Gunthorpe wrote: >> On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote: >>> gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no >>> sense because the source and

Re: [PATCH] net: mlx5: remove pointless memcpy

On 02/02/2018 12:26 PM, Arnd Bergmann wrote: > On Fri, Feb 2, 2018 at 8:06 PM, Jason Gunthorpe wrote: >> On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote: >>> gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no >>> sense because the source and destination variables are

Re: [PATCH 4.15 00/55] 4.15.1-stable review

On Fri, Feb 02, 2018 at 05:58:18PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.1 release. > There are 55 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.15 00/55] 4.15.1-stable review

On Fri, Feb 02, 2018 at 05:58:18PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.1 release. > There are 55 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

Hi Could anyone review an apply this single patch? The 2nd patch had been sent as v2. Regards, Aaron

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

Hi Could anyone review an apply this single patch? The 2nd patch had been sent as v2. Regards, Aaron

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

Hi: Could anyone review and apply these 2 patch? Regards, Aaron

Re: [PATCH v2 2/2] HID: core: Fix size as type u32

Hi: Could anyone review and apply these 2 patch? Regards, Aaron

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 21:53, Chintan Pandya wrote: > > > On 2/2/2018 2:39 AM, Frank Rowand wrote: >> On 02/01/18 06:24, Rob Herring wrote: >>> And so >>> far, no one has explained why a bigger cache got slower. >> >> Yes, I still find that surprising. > > I thought a bit about this. And realized that

Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()

On 02/01/18 21:53, Chintan Pandya wrote: > > > On 2/2/2018 2:39 AM, Frank Rowand wrote: >> On 02/01/18 06:24, Rob Herring wrote: >>> And so >>> far, no one has explained why a bigger cache got slower. >> >> Yes, I still find that surprising. > > I thought a bit about this. And realized that

Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance

On Fri, 2018-02-02 at 13:34 -0500, Steven Sistare wrote: > On 2/2/2018 12:39 PM, Steven Sistare wrote: > > On 2/2/2018 12:21 PM, Peter Zijlstra wrote: > >> On Fri, Feb 02, 2018 at 11:53:40AM -0500, Steven Sistare wrote: > >>> It might be interesting to add a tunable for the number of random

Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance

On Fri, 2018-02-02 at 13:34 -0500, Steven Sistare wrote: > On 2/2/2018 12:39 PM, Steven Sistare wrote: > > On 2/2/2018 12:21 PM, Peter Zijlstra wrote: > >> On Fri, Feb 02, 2018 at 11:53:40AM -0500, Steven Sistare wrote: > >>> It might be interesting to add a tunable for the number of random

Re: [PATCH v2 5/6] arm64: Detect current view of GIC priorities

Hi, Julien On 2018/1/17 19:54, Julien Thierry wrote: The values non secure EL1 needs to use for priority registers depends on the value of SCR_EL3.FIQ. Since we don't have access to SCR_EL3, we fake an interrupt and compare the GIC priority with the one present in the [re]distributor. Also,

Re: [PATCH v2 5/6] arm64: Detect current view of GIC priorities

Hi, Julien On 2018/1/17 19:54, Julien Thierry wrote: The values non secure EL1 needs to use for priority registers depends on the value of SCR_EL3.FIQ. Since we don't have access to SCR_EL3, we fake an interrupt and compare the GIC priority with the one present in the [re]distributor. Also,

[PATCH 2/2] f2fs: add GC_WRITTEN_PAGE to gc atomic file

This patch enables to gc atomic file by adding GC_WRITTEN_PAGE to identify the gced pages of atomic file, which can avoid register_inmem_page in set_page_dirty, so the gced pages will not mix with the inmem pages. Signed-off-by: Yunlong Song --- fs/f2fs/data.c| 7

[PATCH 2/2] f2fs: add GC_WRITTEN_PAGE to gc atomic file

This patch enables to gc atomic file by adding GC_WRITTEN_PAGE to identify the gced pages of atomic file, which can avoid register_inmem_page in set_page_dirty, so the gced pages will not mix with the inmem pages. Signed-off-by: Yunlong Song --- fs/f2fs/data.c| 7 ++- fs/f2fs/gc.c

[PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

If inode has already started to atomic commit, then set_page_dirty will not mix the gc pages with the inmem atomic pages, so the page can be gced safely. Signed-off-by: Yunlong Song --- fs/f2fs/data.c | 5 ++--- fs/f2fs/gc.c | 6 -- 2 files changed, 6

[PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit

If inode has already started to atomic commit, then set_page_dirty will not mix the gc pages with the inmem atomic pages, so the page can be gced safely. Signed-off-by: Yunlong Song --- fs/f2fs/data.c | 5 ++--- fs/f2fs/gc.c | 6 -- 2 files changed, 6 insertions(+), 5 deletions(-) diff

Re: [PATCH v4] Fix loading of module radeonfb on PowerMac

Hi Mathieu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH v4] Fix loading of module radeonfb on PowerMac

Hi Mathieu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15 next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

On (02/03/18 10:34), Sergey Senozhatsky wrote: > so we are basically looking at 4.14-rc0+ [..] > # first bad commit: [bd4c82c22c367e068acb1ec9ec02be2fac3e09e2] mm, THP, swap: > delay splitting THP after swapped out To re-confirm, disabling CONFIG_TRANSPARENT_HUGEPAGE fixes my 4.15.0-next

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

On (02/03/18 10:34), Sergey Senozhatsky wrote: > so we are basically looking at 4.14-rc0+ [..] > # first bad commit: [bd4c82c22c367e068acb1ec9ec02be2fac3e09e2] mm, THP, swap: > delay splitting THP after swapped out To re-confirm, disabling CONFIG_TRANSPARENT_HUGEPAGE fixes my 4.15.0-next

[PATCH v2] x86/perf : Add check for CPUID instruction before using

We still officially support the ancient i486 cpu. First generation versions of this processor do not have the CPUID instruction, though later versions do. Therefore you must check that the cpu supports it before using it. At present it fails with an "Illegal Instruction" signal on the early

[PATCH v2] x86/perf : Add check for CPUID instruction before using

We still officially support the ancient i486 cpu. First generation versions of this processor do not have the CPUID instruction, though later versions do. Therefore you must check that the cpu supports it before using it. At present it fails with an "Illegal Instruction" signal on the early

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

Hi Will, I love your patch! Yet something to improve: [auto build test ERROR on v4.15] [cannot apply to tip/locking/core tip/core/locking tip/auto-latest next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

Hi Will, I love your patch! Yet something to improve: [auto build test ERROR on v4.15] [cannot apply to tip/locking/core tip/core/locking tip/auto-latest next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

Hi Will, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.15] [cannot apply to tip/locking/core tip/core/locking tip/auto-latest next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

Hi Will, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.15] [cannot apply to tip/locking/core tip/core/locking tip/auto-latest next-20180202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

linux-next: Signed-off-by missing for commits in the s390 tree

Hi all, Commits a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call parameter") 279d2cea3aad ("s390/cio: fix kernel-doc usage") are missing a Signed-off-by from their committer. -- Cheers, Stephen Rothwell

linux-next: Signed-off-by missing for commits in the s390 tree

Hi all, Commits a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call parameter") 279d2cea3aad ("s390/cio: fix kernel-doc usage") are missing a Signed-off-by from their committer. -- Cheers, Stephen Rothwell

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

On Wed, Jan 31, 2018 at 05:53:13PM +0100, Daniel Borkmann wrote: > On 01/30/2018 09:50 PM, Eric Leblond wrote: > > Hello Daniel, > > > > No problem with the delay in the answer. I'm doing far worse. > > > > Here is an updated version: > > - add if_link.h in uapi and remove the definition > > -

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

On Wed, Jan 31, 2018 at 05:53:13PM +0100, Daniel Borkmann wrote: > On 01/30/2018 09:50 PM, Eric Leblond wrote: > > Hello Daniel, > > > > No problem with the delay in the answer. I'm doing far worse. > > > > Here is an updated version: > > - add if_link.h in uapi and remove the definition > > -

Re: RFC(V3): Audit Kernel Container IDs

On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote: > On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs wrote: > > Containers are a userspace concept. The kernel knows nothing of them. > > > > The Linux audit system needs a way to be able to track the container > >

Re: RFC(V3): Audit Kernel Container IDs

On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote: > On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs wrote: > > Containers are a userspace concept. The kernel knows nothing of them. > > > > The Linux audit system needs a way to be able to track the container > > provenance of events

bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

Hello, On (01/30/18 11:48), Andrew Morton wrote: > Subject: [Bug 198617] New: zswap causing random applications to crash > > https://bugzilla.kernel.org/show_bug.cgi?id=198617 > > Bug ID: 198617 >Summary: zswap causing random applications to crash >Product:

bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

Hello, On (01/30/18 11:48), Andrew Morton wrote: > Subject: [Bug 198617] New: zswap causing random applications to crash > > https://bugzilla.kernel.org/show_bug.cgi?id=198617 > > Bug ID: 198617 >Summary: zswap causing random applications to crash >Product:

[PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

When the client sends a regular blocking accept request, the backend is expected to return only when the accept is completed, simulating a blocking behavior, or return an error. Specifically, on EAGAIN from inet_accept, the backend shouldn't return "EAGAIN" to the client. Instead, it should

[PATCH] pvcalls-back: do not return error on inet_accept EAGAIN

When the client sends a regular blocking accept request, the backend is expected to return only when the accept is completed, simulating a blocking behavior, or return an error. Specifically, on EAGAIN from inet_accept, the backend shouldn't return "EAGAIN" to the client. Instead, it should

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote: > Recent efforts led to the specification of a memory consistency model > for the Linux kernel [1], which "can (roughly speaking) be thought of > as an automated version of memory-barriers.txt" and which is (in turn) > "accompanied by

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote: > Recent efforts led to the specification of a memory consistency model > for the Linux kernel [1], which "can (roughly speaking) be thought of > as an automated version of memory-barriers.txt" and which is (in turn) > "accompanied by

[PATCH v4 4/5] irqchip/gic-v3-its: add ability to resend MAPC on resume

This adds functionality to resend the MAPC command to an ITS node on resume. If the ITS is powered down during suspend and the collections are not backed by memory, the ITS will lose that state. This just sets up the known state for the collections after the ITS is restored. This feature is

[PATCH v4 4/5] irqchip/gic-v3-its: add ability to resend MAPC on resume

This adds functionality to resend the MAPC command to an ITS node on resume. If the ITS is powered down during suspend and the collections are not backed by memory, the ITS will lose that state. This just sets up the known state for the collections after the ITS is restored. This feature is

[PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state

Some platforms power off GIC logic in suspend, so we need to save/restore state. The distributor and redistributor registers need to be handled in platform code due to access permissions on those registers, but the ITS registers can be restored in the kernel. Signed-off-by: Derek Basehore

[PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state

Some platforms power off GIC logic in suspend, so we need to save/restore state. The distributor and redistributor registers need to be handled in platform code due to access permissions on those registers, but the ITS registers can be restored in the kernel. Signed-off-by: Derek Basehore ---

[PATCH v4 5/5] DT/arm,gic-v3: add collections-reset-on-suspend property

This boolean property for the GIC-V3-ITS enables resending the MAP COLLECTIONS commands when resuming for when the state is reset on suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 4 1 file changed,

[PATCH v4 5/5] DT/arm,gic-v3: add collections-reset-on-suspend property

This boolean property for the GIC-V3-ITS enables resending the MAP COLLECTIONS commands when resuming for when the state is reset on suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 4 1 file changed, 4 insertions(+) diff

[PATCH v4 3/5] DT/arm,gic-v3-its: add reset-on-suspend property

This adds documentation for the new reset-on-suspend property. This property enables saving and restoring the ITS for when it loses state in system suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++ 1

[PATCH v4 3/5] DT/arm,gic-v3-its: add reset-on-suspend property

This adds documentation for the new reset-on-suspend property. This property enables saving and restoring the ITS for when it loses state in system suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++ 1 file changed, 3

[PATCH v4 1/5] cpu_pm: add syscore_suspend error handling

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This will put the CPU in the correct state to resume from the failure. Signed-off-by: Derek Basehore --- kernel/cpu_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu_pm.c

[PATCH v4 1/5] cpu_pm: add syscore_suspend error handling

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This will put the CPU in the correct state to resume from the failure. Signed-off-by: Derek Basehore --- kernel/cpu_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c index

[PATCH v4 0/5] GICv3 Save and Restore

A lot of changes in v2. The distributor and redistributor saving and restoring is left to the PSCI/firmware implementation after discussions with ARM. This reduces the line changes by a lot and removes now unneeded patches. Patches are verified on an RK3399 platform with pending patches in the

[PATCH v4 0/5] GICv3 Save and Restore

A lot of changes in v2. The distributor and redistributor saving and restoring is left to the PSCI/firmware implementation after discussions with ARM. This reduces the line changes by a lot and removes now unneeded patches. Patches are verified on an RK3399 platform with pending patches in the

cris-linux-ld: cannot open linker script file ./arch/cris/kernel/vmlinux.lds: No such file or directory

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b89e32ccd1be92a3643df3908d3026b09e271616 commit: 0fbc0b67a89d756ae3a839be01440e54348159a0 cris: remove arch specific early DT functions date: 3 days ago config: cris-defconfig (attached as .config)

cris-linux-ld: cannot open linker script file ./arch/cris/kernel/vmlinux.lds: No such file or directory

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b89e32ccd1be92a3643df3908d3026b09e271616 commit: 0fbc0b67a89d756ae3a839be01440e54348159a0 cris: remove arch specific early DT functions date: 3 days ago config: cris-defconfig (attached as .config)

Inquiry about your product/ From exportersindia_ Awaiting your reply.

I am interested in your Product i got your listing from exportersindia.com we need large quantites of about 100pcs. Pls send a mail for business discussions at kmike2...@gmail.com so as to carryout orders and payment as soon as possibles. Mike Kennedy CEO 9037623258 USA www.goodman.com

Inquiry about your product/ From exportersindia_ Awaiting your reply.

I am interested in your Product i got your listing from exportersindia.com we need large quantites of about 100pcs. Pls send a mail for business discussions at kmike2...@gmail.com so as to carryout orders and payment as soon as possibles. Mike Kennedy CEO 9037623258 USA www.goodman.com

Re: [PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

On Fri, Feb 02, 2018 at 03:51:02PM -0800, Paul E. McKenney wrote: > On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote: > > Now that a formal specification of the LKMM has become available to > > the developer, some concern about how to track changes to the model > > on the level of the

Re: [PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

On Fri, Feb 02, 2018 at 03:51:02PM -0800, Paul E. McKenney wrote: > On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote: > > Now that a formal specification of the LKMM has become available to > > the developer, some concern about how to track changes to the model > > on the level of the

[GIT] Networking

1) The bnx2x can hang if you give it a GSO packet with a segment size which is too big for the hardware, detect and drop in this case. From Daniel Axtens. 2) Fix some overflows and pointer leaks in xtables, from Dmitry Vyukov. 3) Missing RCU locking in igmp, from Eric Dumazet. 4) Fix

[GIT] Networking

1) The bnx2x can hang if you give it a GSO packet with a segment size which is too big for the hardware, detect and drop in this case. From Daniel Axtens. 2) Fix some overflows and pointer leaks in xtables, from Dmitry Vyukov. 3) Missing RCU locking in igmp, from Eric Dumazet. 4) Fix

Re: [GIT PULL] pin control bulk changes for v4.16

On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds wrote: > > Stupid patch attached. I don't know how much this helps the insane > dependency hell for , but it's bound to help > _some_. Testing it, that patch definitely cuts down on recompiles after touch

Re: [GIT PULL] pin control bulk changes for v4.16

On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds wrote: > > Stupid patch attached. I don't know how much this helps the insane > dependency hell for , but it's bound to help > _some_. Testing it, that patch definitely cuts down on recompiles after touch include/linux/pinctrl/devinfo.h a

[PATCH v7 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

Debugfs extension for Intel IOMMU to dump Interrupt remapping table entries for Interrupt remapping and Interrupt posting. The file /sys/kernel/debug/intel_iommu/ir_translation_struct provides detailed information, such as Index, Source Id, Destination Id, Vector and the IRTE values for entries

[PATCH v7 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

Debugfs extension for Intel IOMMU to dump Interrupt remapping table entries for Interrupt remapping and Interrupt posting. The file /sys/kernel/debug/intel_iommu/ir_translation_struct provides detailed information, such as Index, Source Id, Destination Id, Vector and the IRTE values for entries

[PATCH v7 3/5] iommu/vt-d: Add debugfs support to show register contents

From: Gayatri Kammela Debugfs extension to dump all the register contents for each IOMMU device to the user space via debugfs. Example: root@OTC-KBLH-01:~# cat /sys/kernel/debug/intel_iommu/iommu_regset DMAR: dmar0: Register Base Address fed9 Name

[PATCH v7 3/5] iommu/vt-d: Add debugfs support to show register contents

From: Gayatri Kammela Debugfs extension to dump all the register contents for each IOMMU device to the user space via debugfs. Example: root@OTC-KBLH-01:~# cat /sys/kernel/debug/intel_iommu/iommu_regset DMAR: dmar0: Register Base Address fed9 NameOffset Contents VER

[PATCH v7 0/5] Add Intel IOMMU debugfs support

Hi All, This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU registers, internal context and dumps individual table entries to help debug Intel IOMMUs. The first patch does the ground work for the following patches by reorganizing some Intel IOMMU data structures. The

[PATCH v7 0/5] Add Intel IOMMU debugfs support

Hi All, This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU registers, internal context and dumps individual table entries to help debug Intel IOMMUs. The first patch does the ground work for the following patches by reorganizing some Intel IOMMU data structures. The

  1   2   3   4   5   6   7   8   9   10   >