[PATCH 3/5] arm64: dts: hisi: add RoCE nodes for the hip07 SoC

From: Wei Xu Add the infiniband node to support the RoCE function on the hip07 SoC. Signed-off-by: Wei Xu --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 81 1 file changed, 81 insertions(+) diff --git

[PATCH 4/5] arm64: dts: hisi: add SAS nodes for the hip07 SoC

From: Wei Xu Add 3 SAS host controller nodes and the dependent subctrl node to enable the SAS and SATA function for the hip07 SoC. Signed-off-by: Wei Xu --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 129 +++ 1 file

[PATCH 5/5] arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board

From: Wei Xu Enalbe the NIC and SAS nodes for the hip07-d05 board to support related functions. Signed-off-by: Wei Xu --- arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 1 file changed, 24 insertions(+) diff --git

[PATCH 3/5] arm64: dts: hisi: add RoCE nodes for the hip07 SoC

From: Wei Xu Add the infiniband node to support the RoCE function on the hip07 SoC. Signed-off-by: Wei Xu --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 81 1 file changed, 81 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi

[PATCH 4/5] arm64: dts: hisi: add SAS nodes for the hip07 SoC

From: Wei Xu Add 3 SAS host controller nodes and the dependent subctrl node to enable the SAS and SATA function for the hip07 SoC. Signed-off-by: Wei Xu --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 129 +++ 1 file changed, 129 insertions(+) diff --git

[PATCH 5/5] arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board

From: Wei Xu Enalbe the NIC and SAS nodes for the hip07-d05 board to support related functions. Signed-off-by: Wei Xu --- arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 1 file changed, 24 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts

Re: [PATCH -mm -v2] mm, swap: Use kvzalloc to allocate some swap data structure

Hi, Matthew, Matthew Wilcox writes: > On Wed, Apr 05, 2017 at 03:10:58PM +0800, Huang, Ying wrote: >> In general, kmalloc() will have less memory fragmentation than >> vmalloc(). From Dave Hansen: For example, we have a two-page data >> structure. vmalloc() takes two

Re: [PATCH -mm -v2] mm, swap: Use kvzalloc to allocate some swap data structure

Hi, Matthew, Matthew Wilcox writes: > On Wed, Apr 05, 2017 at 03:10:58PM +0800, Huang, Ying wrote: >> In general, kmalloc() will have less memory fragmentation than >> vmalloc(). From Dave Hansen: For example, we have a two-page data >> structure. vmalloc() takes two effectively random

Re: tty crash in tty_ldisc_receive_buf()

On Thu, Apr 06, 2017 at 05:04:41PM +1000, Michael Neuling wrote: > Hi all, > > We are seeing the following crash (in linux-next but has been around since at > least v4.10). > > [  417.514499] Unable to handle kernel paging request for data at address > 0x2260 > [  417.515361] Faulting

Re: tty crash in tty_ldisc_receive_buf()

On Thu, Apr 06, 2017 at 05:04:41PM +1000, Michael Neuling wrote: > Hi all, > > We are seeing the following crash (in linux-next but has been around since at > least v4.10). > > [  417.514499] Unable to handle kernel paging request for data at address > 0x2260 > [  417.515361] Faulting

[PATCH 2/2] block: trace completion of all bios.

Currently only dm and md/raid5 bios trigger trace_block_bio_complete(). Now that we have bio_chain() and bio_inc_remaining(), it is not possible, in general, for a driver to know when the bio is really complete. Only bio_endio() knows that. So move the trace_block_bio_complete() call to

[PATCH 2/2] block: trace completion of all bios.

Currently only dm and md/raid5 bios trigger trace_block_bio_complete(). Now that we have bio_chain() and bio_inc_remaining(), it is not possible, in general, for a driver to know when the bio is really complete. Only bio_endio() knows that. So move the trace_block_bio_complete() call to

[PATCH 1/2] block: simple improvements for bio->flags

The comment for the 'flags' field of 'bio' mentions "command" which is no longer stored there, and doesn't mention the bvec pool number, which is. BIO_RESET_BITS is set in such a way that it would need to be updated if new bits were added, which is easy to miss. BVEC_POOL_BITS is larger than

[PATCH 1/2] block: simple improvements for bio->flags

The comment for the 'flags' field of 'bio' mentions "command" which is no longer stored there, and doesn't mention the bvec pool number, which is. BIO_RESET_BITS is set in such a way that it would need to be updated if new bits were added, which is easy to miss. BVEC_POOL_BITS is larger than

[PATCH 0/2] Trace completion of all bios

Hi Jens, I think all objections to this patch have been answered so I'm resending. I've added a small cleanup patch first which makes some small enhancements to the documentation and #defines for the bio->flags field. Thanks, NeilBrown --- NeilBrown (2): block: simple improvements

[PATCH 0/2] Trace completion of all bios

Hi Jens, I think all objections to this patch have been answered so I'm resending. I've added a small cleanup patch first which makes some small enhancements to the documentation and #defines for the bio->flags field. Thanks, NeilBrown --- NeilBrown (2): block: simple improvements

Re: tty crash in tty_ldisc_receive_buf()

On Thu, 2017-04-06 at 08:28 -0500, Rob Herring wrote: > > Can you try this one [1]. > > Rob > > [1] https://lkml.org/lkml/2017/3/23/569 Unless I missed something, that patch doesn't change barriers or locking, so I don't see how it could fix anything ... Mind you we haven't quite figured out

Re: tty crash in tty_ldisc_receive_buf()

On Thu, 2017-04-06 at 08:28 -0500, Rob Herring wrote: > > Can you try this one [1]. > > Rob > > [1] https://lkml.org/lkml/2017/3/23/569 Unless I missed something, that patch doesn't change barriers or locking, so I don't see how it could fix anything ... Mind you we haven't quite figured out

Re: tty crash in tty_ldisc_receive_buf()

> > If anyone has an idea, I'm happy to try a patch. > > Can you try this one [1]. Rob, I'm still hitting it when I apply that on next-20170405. Crash below.. Any other clues? [  229.422825] Unable to handle kernel paging request for data at address 0x2260 [  229.423681] Faulting

Re: tty crash in tty_ldisc_receive_buf()

> > If anyone has an idea, I'm happy to try a patch. > > Can you try this one [1]. Rob, I'm still hitting it when I apply that on next-20170405. Crash below.. Any other clues? [  229.422825] Unable to handle kernel paging request for data at address 0x2260 [  229.423681] Faulting

Re: [PATCH 2/9] mm: support __GFP_REPEAT in kvmalloc_node for >32kB

On Mon, Mar 6, 2017 at 2:30 AM, Michal Hocko wrote: > From: Michal Hocko > > vhost code uses __GFP_REPEAT when allocating vhost_virtqueue resp. > vhost_vsock because it would really like to prefer kmalloc to the > vmalloc fallback - see 23cc5a991c7a

Re: [PATCH 2/9] mm: support __GFP_REPEAT in kvmalloc_node for >32kB

On Mon, Mar 6, 2017 at 2:30 AM, Michal Hocko wrote: > From: Michal Hocko > > vhost code uses __GFP_REPEAT when allocating vhost_virtqueue resp. > vhost_vsock because it would really like to prefer kmalloc to the > vmalloc fallback - see 23cc5a991c7a ("vhost-net: extend device > allocation to

Re: [PATCH v3 7/8] mm, compaction: restrict async compaction to pageblocks of same migratetype

On Wed, Mar 29, 2017 at 06:06:41PM +0200, Vlastimil Babka wrote: > On 03/16/2017 03:14 AM, Joonsoo Kim wrote: > > On Tue, Mar 07, 2017 at 02:15:44PM +0100, Vlastimil Babka wrote: > >> The migrate scanner in async compaction is currently limited to > >> MIGRATE_MOVABLE > >> pageblocks. This is a

Re: [PATCH v3 7/8] mm, compaction: restrict async compaction to pageblocks of same migratetype

On Wed, Mar 29, 2017 at 06:06:41PM +0200, Vlastimil Babka wrote: > On 03/16/2017 03:14 AM, Joonsoo Kim wrote: > > On Tue, Mar 07, 2017 at 02:15:44PM +0100, Vlastimil Babka wrote: > >> The migrate scanner in async compaction is currently limited to > >> MIGRATE_MOVABLE > >> pageblocks. This is a

Re: [RFC][CFT][PATCHSET v2] uaccess unification

On Fri, Apr 07, 2017 at 01:24:24AM +0100, Al Viro wrote: > * ibmvnet bugs spotted and fixed; that'll get fed into net-next > ASAP. ... except that net-next had them fixed in much better way - by removing the crap in question completely. Commit dropped.

Re: [RFC][CFT][PATCHSET v2] uaccess unification

On Fri, Apr 07, 2017 at 01:24:24AM +0100, Al Viro wrote: > * ibmvnet bugs spotted and fixed; that'll get fed into net-next > ASAP. ... except that net-next had them fixed in much better way - by removing the crap in question completely. Commit dropped.

[PATCH] padata: free correct variable

The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- kernel/padata.c | 2 +- 1 file changed, 1

[PATCH] padata: free correct variable

The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- kernel/padata.c | 2 +- 1 file changed, 1 insertion(+), 1

[RFC][CFT][PATCHSET v2] uaccess unification

Updates since v1: * metag conversion (based on fixes from James Hogan) added. Result tested by the aforementioned metag maintainer. * xtensa fix added, result tested. * arm, arm64, amd64 tested. * s390 fix folded, result tested. * arc fix added, result

[RFC][CFT][PATCHSET v2] uaccess unification

Updates since v1: * metag conversion (based on fixes from James Hogan) added. Result tested by the aforementioned metag maintainer. * xtensa fix added, result tested. * arm, arm64, amd64 tested. * s390 fix folded, result tested. * arc fix added, result

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

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/ibm/ibmvnic.c between commit: 98998345a579 ("ibmvnic: fix kstrtoul, copy_from_user and copy_to_user misuse") from the vfs tree and commit: e704f0434ea6 ("ibmvnic: Remove debugfs support")

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

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/ibm/ibmvnic.c between commit: 98998345a579 ("ibmvnic: fix kstrtoul, copy_from_user and copy_to_user misuse") from the vfs tree and commit: e704f0434ea6 ("ibmvnic: Remove debugfs support")

[PATCH] staging: sm750fb: ddk750_display.c - fixed checkpatch warning: line over 80 chars

staging: sm750fb: ddk750_display.c - fixed the following checkpatch warning: WARNING: line over 80 characters #149: FILE: drivers/staging/sm750fb/ddk750_display.c:149: + swPanelPowerSequence((output & PNL_SEQ_MASK) >> PNL_SEQ_OFFSET, 4); Signed-off-by: Andrea della Porta

[PATCH] staging: sm750fb: ddk750_display.c - fixed checkpatch warning: line over 80 chars

staging: sm750fb: ddk750_display.c - fixed the following checkpatch warning: WARNING: line over 80 characters #149: FILE: drivers/staging/sm750fb/ddk750_display.c:149: + swPanelPowerSequence((output & PNL_SEQ_MASK) >> PNL_SEQ_OFFSET, 4); Signed-off-by: Andrea della Porta ---

Re: [PATCH v2 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller

On 03/31/2017 07:02 PM, Ludovic Barre wrote: > From: Ludovic Barre > > The quadspi is a specialized communication interface targeting single, > dual or quad SPI Flash memories. > > It can operate in any of the following modes: > -indirect mode: all the operations are

Re: [PATCH v2 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller

On 03/31/2017 07:02 PM, Ludovic Barre wrote: > From: Ludovic Barre > > The quadspi is a specialized communication interface targeting single, > dual or quad SPI Flash memories. > > It can operate in any of the following modes: > -indirect mode: all the operations are performed using the quadspi

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: > Before this patch, m25p80_read() supported few SPI protocols: > - regular SPI 1-1-1 > - SPI Dual Output 1-1-2 > - SPI Quad Output 1-1-4 > On the other hand, m25p80_write() only supported SPI 1-1-1. > > This patch updates both m25p80_read() and

Re: [PATCH v5 2/6] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: > Before this patch, m25p80_read() supported few SPI protocols: > - regular SPI 1-1-1 > - SPI Dual Output 1-1-2 > - SPI Quad Output 1-1-4 > On the other hand, m25p80_write() only supported SPI 1-1-1. > > This patch updates both m25p80_read() and

Re: [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode

On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: > This patch changes the prototype of spi_nor_scan(): its 3rd parameter > is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor > framework about the actual hardware capabilities supported by the SPI > controller and its driver. >

Re: [PATCH v5 1/6] mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode

On 03/23/2017 12:33 AM, Cyrille Pitchen wrote: > This patch changes the prototype of spi_nor_scan(): its 3rd parameter > is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor > framework about the actual hardware capabilities supported by the SPI > controller and its driver. >

[PATCH] staging: comedi: drivers: s626.c - fixed checkpatch issue about data type

staging: comedi: drivers: s626.c - fixed the following checkpatch issue: CHECK: Prefer kernel type 's16' over 'int16_t' #1939: FILE: drivers/staging/comedi/drivers/s626.c:1939: + int16_t dacdata = (int16_t)data[i]; Signed-off-by: Andrea della Porta ---

[PATCH] staging: comedi: drivers: s626.c - fixed checkpatch issue about data type

staging: comedi: drivers: s626.c - fixed the following checkpatch issue: CHECK: Prefer kernel type 's16' over 'int16_t' #1939: FILE: drivers/staging/comedi/drivers/s626.c:1939: + int16_t dacdata = (int16_t)data[i]; Signed-off-by: Andrea della Porta ---

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

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/sched/sch_generic.c between commit: 92f9170621a1 ("net_sched: check noop_qdisc before qdisc_hash_add()") from the net tree and commit: 49b499718fa1 ("net: sched: make default fifo qdiscs appear in the dump")

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

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/sched/sch_generic.c between commit: 92f9170621a1 ("net_sched: check noop_qdisc before qdisc_hash_add()") from the net tree and commit: 49b499718fa1 ("net: sched: make default fifo qdiscs appear in the dump")

[PATCH] Rename tsk_restore_flags() to current_restore_flags()

It is not safe for one thread to modify the ->flags of another thread as there is no locking that can protect the update. So tsk_restore_flags(), which takes a task pointer and modifies the flags, is an invitation to do the wrong thing. All current users pass "current" as the task, so no

[PATCH] Rename tsk_restore_flags() to current_restore_flags()

It is not safe for one thread to modify the ->flags of another thread as there is no locking that can protect the update. So tsk_restore_flags(), which takes a task pointer and modifies the flags, is an invitation to do the wrong thing. All current users pass "current" as the task, so no

[PATCH] cgroup: move cgroup_subsys_state partner field for cache locality

From: Todd Poynor Various structures embed a struct cgroup_subsys_state, typically at the top of the containing structure. It is common for code that accesses the structures to perform operations that iterate over the chain of parent css pointers, also accessing data in

[PATCH] cgroup: move cgroup_subsys_state partner field for cache locality

From: Todd Poynor Various structures embed a struct cgroup_subsys_state, typically at the top of the containing structure. It is common for code that accesses the structures to perform operations that iterate over the chain of parent css pointers, also accessing data in each containing

[PATCH] staging: rts5208: ms.c fixed checkpatch warning - using __func__ instead of hardcoded name

staging: rts5208: ms.c Fixed checkpatch warning: WARNING: Prefer using "%s", __func__ to embedded function names #2597: FILE: rts5208/ms.c:2597: + dev_dbg(rtsx_dev(chip), "ms_build_l2p_tbl: %d\n", seg_no); Signed-off-by: Andrea della Porta ---

[PATCH] staging: rts5208: ms.c fixed checkpatch warning - using __func__ instead of hardcoded name

staging: rts5208: ms.c Fixed checkpatch warning: WARNING: Prefer using "%s", __func__ to embedded function names #2597: FILE: rts5208/ms.c:2597: + dev_dbg(rtsx_dev(chip), "ms_build_l2p_tbl: %d\n", seg_no); Signed-off-by: Andrea della Porta --- drivers/staging/rts5208/ms.c | 2 +- 1 file

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, 6 Apr 2017 15:08:21 -0700 "Paul E. McKenney" wrote: > On Thu, Apr 06, 2017 at 05:23:48PM -0400, Steven Rostedt wrote: > > On Thu, 6 Apr 2017 13:21:17 -0700 > > "Paul E. McKenney" wrote: > > > > > > My worry is that we add

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, 6 Apr 2017 15:08:21 -0700 "Paul E. McKenney" wrote: > On Thu, Apr 06, 2017 at 05:23:48PM -0400, Steven Rostedt wrote: > > On Thu, 6 Apr 2017 13:21:17 -0700 > > "Paul E. McKenney" wrote: > > > > > > My worry is that we add another caller that doesn't disable interrupts > > > > or

Re: [PATCH] ath9k: Add cast to u8 to FREQ2FBIN macro

Hi Joe, El Thu, Apr 06, 2017 at 02:29:20PM -0700 Joe Perches ha dit: > On Thu, 2017-04-06 at 14:21 -0700, Matthias Kaehlcke wrote: > > The macro results are assigned to u8 variables/fields. Adding the cast > > fixes plenty of clang warnings about "implicit conversion from 'int' to > > 'u8'". > >

Re: [PATCH] ath9k: Add cast to u8 to FREQ2FBIN macro

Hi Joe, El Thu, Apr 06, 2017 at 02:29:20PM -0700 Joe Perches ha dit: > On Thu, 2017-04-06 at 14:21 -0700, Matthias Kaehlcke wrote: > > The macro results are assigned to u8 variables/fields. Adding the cast > > fixes plenty of clang warnings about "implicit conversion from 'int' to > > 'u8'". > >

Re: [PATCH v6 19/39] media: Add i.MX media core driver

On 04/06/2017 02:43 AM, Philipp Zabel wrote: On Mon, 2017-03-27 at 17:40 -0700, Steve Longerbeam wrote: Add the core media driver for i.MX SOC. Signed-off-by: Steve Longerbeam [...] diff --git a/drivers/staging/media/imx/imx-media-of.c

Re: [PATCH v6 19/39] media: Add i.MX media core driver

On 04/06/2017 02:43 AM, Philipp Zabel wrote: On Mon, 2017-03-27 at 17:40 -0700, Steve Longerbeam wrote: Add the core media driver for i.MX SOC. Signed-off-by: Steve Longerbeam [...] diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c new file

[PATCH v3] loop: Add PF_LESS_THROTTLE to block/loop device thread.

When a filesystem is mounted from a loop device, writes are throttled by balance_dirty_pages() twice: once when writing to the filesystem and once when the loop_handle_cmd() writes to the backing file. This double-throttling can trigger positive feedback loops that create significant delays.

[PATCH v3] loop: Add PF_LESS_THROTTLE to block/loop device thread.

When a filesystem is mounted from a loop device, writes are throttled by balance_dirty_pages() twice: once when writing to the filesystem and once when the loop_handle_cmd() writes to the backing file. This double-throttling can trigger positive feedback loops that create significant delays.

Greetings to you and your family,

-- Greetings to you and your family, Good Day, I am writing to request your assistance to transfer the sum of $8, 600.000.00 (Eight million Six hundred thousand USD) to your country. Please delete it if you are not interested. The total sum will be shared as follows: 60% for me, 40% for you.

Greetings to you and your family,

-- Greetings to you and your family, Good Day, I am writing to request your assistance to transfer the sum of $8, 600.000.00 (Eight million Six hundred thousand USD) to your country. Please delete it if you are not interested. The total sum will be shared as follows: 60% for me, 40% for you.

Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797

Hi Stephen On Thu, 2017-04-06 at 13:08 -0700, Stephen Boyd wrote: > On 03/19, Mars Cheng wrote: > > From: Kevin-CW Chen > > > > Add MT6797 clock support, include topckgen, apmixedsys, infracfg > > and subsystem clocks > > > > Signed-off-by: Kevin-CW Chen

Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797

Hi Stephen On Thu, 2017-04-06 at 13:08 -0700, Stephen Boyd wrote: > On 03/19, Mars Cheng wrote: > > From: Kevin-CW Chen > > > > Add MT6797 clock support, include topckgen, apmixedsys, infracfg > > and subsystem clocks > > > > Signed-off-by: Kevin-CW Chen > > Signed-off-by: Mars Cheng > >

[PATCH v2] mac80211: Fix clang warning about constant operand in logical operation

When clang detects a non-boolean constant in a logical operation it generates a 'constant-logical-operand' warning. In ieee80211_try_rate_control_ops_get() the result of strlen() is used in a logical operation, clang resolves the expression to an (integer) constant at compile time when clang's

[PATCH v2] mac80211: Fix clang warning about constant operand in logical operation

When clang detects a non-boolean constant in a logical operation it generates a 'constant-logical-operand' warning. In ieee80211_try_rate_control_ops_get() the result of strlen() is used in a logical operation, clang resolves the expression to an (integer) constant at compile time when clang's

linux-next: manual merge of the vfs tree with the s390 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: arch/s390/Kconfig between commit: 59cea29a34eb ("s390: remove HAVE_ARCH_EARLY_PFN_TO_NID select statement") from the s390 tree and commit: 37df4b8ce129 ("HAVE_ARCH_HARDENED_USERCOPY is unconditional now") from the vfs

linux-next: manual merge of the vfs tree with the s390 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: arch/s390/Kconfig between commit: 59cea29a34eb ("s390: remove HAVE_ARCH_EARLY_PFN_TO_NID select statement") from the s390 tree and commit: 37df4b8ce129 ("HAVE_ARCH_HARDENED_USERCOPY is unconditional now") from the vfs

[PATCHv2 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers to encode their information. It collides with valid pointers with 5-level paging and leads to

[PATCHv2 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers to encode their information. It collides with valid pointers with 5-level paging and leads to

[PATCH 4/5] i915: schedule while freeing the lists of gem objects

Add cond_resched(). Signed-off-by: Andrea Arcangeli --- drivers/gpu/drm/i915/i915_gem.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 612fde3..c81baeb 100644 ---

[PATCH 4/5] i915: schedule while freeing the lists of gem objects

Add cond_resched(). Signed-off-by: Andrea Arcangeli --- drivers/gpu/drm/i915/i915_gem.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 612fde3..c81baeb 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++

[PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

Waiting a RCU grace period only guarantees the work gets queued, but until after the queued workqueue returns, there's no guarantee the memory was actually freed. So flush the work to provide better guarantees to the reclaim code in addition of waiting a RCU grace period to pass. Signed-off-by:

[PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

Waiting a RCU grace period only guarantees the work gets queued, but until after the queued workqueue returns, there's no guarantee the memory was actually freed. So flush the work to provide better guarantees to the reclaim code in addition of waiting a RCU grace period to pass. Signed-off-by:

[PATCH 5/5] i915: fence workqueue optimization

Insist to run llist_del_all() until the free_list is found empty, this may avoid having to schedule more workqueues. Signed-off-by: Andrea Arcangeli --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

I'm also getting kernel hangs every couple of days. For me it's still not fixed here in 4.11-rc5. It's hard to reproduce, the best reproducer is to build lineageos 14.1 on host while running LTP in a guest to stress the guest VM. Initially I thought it was related to the fact I upgraded the xf86

[PATCH 5/5] i915: fence workqueue optimization

Insist to run llist_del_all() until the free_list is found empty, this may avoid having to schedule more workqueues. Signed-off-by: Andrea Arcangeli --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

I'm also getting kernel hangs every couple of days. For me it's still not fixed here in 4.11-rc5. It's hard to reproduce, the best reproducer is to build lineageos 14.1 on host while running LTP in a guest to stress the guest VM. Initially I thought it was related to the fact I upgraded the xf86

[PATCH 3/5] i915: initialize the free_list of the fencing atomic_helper

Just in case the llist model changes and NULL isn't valid initialization. Signed-off-by: Andrea Arcangeli --- drivers/gpu/drm/i915/intel_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_display.c

[PATCH 1/5] i915: avoid kernel hang caused by synchronize rcu struct_mutex deadlock

synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will hang until its own workqueues are run. The i915 gem workqueues will wait on the struct_mutex to be released. So we cannot wait for a quiescent state using those rcu primitives while holding the struct_mutex or it creates a circular

[PATCH 3/5] i915: initialize the free_list of the fencing atomic_helper

Just in case the llist model changes and NULL isn't valid initialization. Signed-off-by: Andrea Arcangeli --- drivers/gpu/drm/i915/intel_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index

[PATCH 1/5] i915: avoid kernel hang caused by synchronize rcu struct_mutex deadlock

synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will hang until its own workqueues are run. The i915 gem workqueues will wait on the struct_mutex to be released. So we cannot wait for a quiescent state using those rcu primitives while holding the struct_mutex or it creates a circular

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: > On 04/06/2017 09:43 PM, Dmitry Safonov wrote: > > Hi Kirill, > > > > On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: > > > On x86, 5-level paging enables 56-bit userspace virtual address space. > > > Not all user space is ready

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: > On 04/06/2017 09:43 PM, Dmitry Safonov wrote: > > Hi Kirill, > > > > On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: > > > On x86, 5-level paging enables 56-bit userspace virtual address space. > > > Not all user space is ready

[RFC PATCH 0/2] dmabuf import interfaces for vgem

Hi, Ion[1] is making progress towards moving out of staging. I'd like to take advantage of the vgem driver for development of unit tests for Ion. To do this properly, vgem needs to support importing of foreign handles. This is an RFC to add that support. This passes the existing vgem_basic unit

[RFC PATCH 0/2] dmabuf import interfaces for vgem

Hi, Ion[1] is making progress towards moving out of staging. I'd like to take advantage of the vgem driver for development of unit tests for Ion. To do this properly, vgem needs to support importing of foreign handles. This is an RFC to add that support. This passes the existing vgem_basic unit

[RFC PATCH 1/2] drm/vgem: Add a dummy platform device

The vgem driver is currently registered independent of any actual device. Some usage of the dmabuf APIs require an actual device structure to do anything. Register a dummy platform device for use with dmabuf. Signed-off-by: Laura Abbott --- I realize the original driver had a

[RFC PATCH 1/2] drm/vgem: Add a dummy platform device

The vgem driver is currently registered independent of any actual device. Some usage of the dmabuf APIs require an actual device structure to do anything. Register a dummy platform device for use with dmabuf. Signed-off-by: Laura Abbott --- I realize the original driver had a note about 'drop

[RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

Enable the GEM dma-buf import interfaces in addition to the export interfaces. This lets vgem be used as a test source for other allocators (e.g. Ion). Signed-off-by: Laura Abbott --- drivers/gpu/drm/vgem/vgem_drv.c | 135

[RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

Enable the GEM dma-buf import interfaces in addition to the export interfaces. This lets vgem be used as a test source for other allocators (e.g. Ion). Signed-off-by: Laura Abbott --- drivers/gpu/drm/vgem/vgem_drv.c | 135

Re: [PATCH][-next] nfp: don't dereference a null nn->eth_port to print a warning

On Thu, 6 Apr 2017 13:54:35 +0100, Colin King wrote: > From: Colin Ian King > > On the case where nn->eth_port is null the warning message > is printing the port by dereferencing this null pointer. > Remove the deference to avoid a crash when printing the > warning

Re: [PATCH][-next] nfp: don't dereference a null nn->eth_port to print a warning

On Thu, 6 Apr 2017 13:54:35 +0100, Colin King wrote: > From: Colin Ian King > > On the case where nn->eth_port is null the warning message > is printing the port by dereferencing this null pointer. > Remove the deference to avoid a crash when printing the > warning message. > > Detected by

Re: [PATCH] cs-2000-cp: keep Reserved bit on each register

On 04/05, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > Thus CS2000 datasheet is indicating below, this patch > follows it. > > WARNING: All "Reserved" registers must maintain their default > state to ensure proper functional operation. >

Re: [PATCH] cs-2000-cp: keep Reserved bit on each register

On 04/05, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > Thus CS2000 datasheet is indicating below, this patch > follows it. > > WARNING: All "Reserved" registers must maintain their default > state to ensure proper functional operation. > > Signed-off-by: Kuninori Morimoto

Re: [PATCH] pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()

On Thu, Mar 30, 2017 at 6:16 PM, Tony Lindgren wrote: > Recent pinctrl changes to allow dynamic allocation of pins exposed one > more issue with the pinctrl pins claimed early by the controller itself. > This caused a regression for IMX6 pinctrl hogs. > > Before enabling the

Re: [PATCH] pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()

On Thu, Mar 30, 2017 at 6:16 PM, Tony Lindgren wrote: > Recent pinctrl changes to allow dynamic allocation of pins exposed one > more issue with the pinctrl pins claimed early by the controller itself. > This caused a regression for IMX6 pinctrl hogs. > > Before enabling the pin controller

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

El Fri, Apr 07, 2017 at 12:51:57AM +0200 Johannes Berg ha dit: > On Thu, 2017-04-06 at 15:42 -0700, Matthias Kaehlcke wrote: > > > > Thanks, it would also require to move the initialization of > > ieee80211_default_rc_algo into an ifdef. If you can live with such a > > solution I'm happy to

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

El Fri, Apr 07, 2017 at 12:51:57AM +0200 Johannes Berg ha dit: > On Thu, 2017-04-06 at 15:42 -0700, Matthias Kaehlcke wrote: > > > > Thanks, it would also require to move the initialization of > > ieee80211_default_rc_algo into an ifdef. If you can live with such a > > solution I'm happy to

Re: [PATCH] net: ipv4: netfilter: Remove unused function nf_nat_need_gre()

On Sat, Apr 01, 2017 at 07:06:33PM +0530, simran singhal wrote: > The function nf_nat_need_gre() on being called, simply returns > back. The function doesn't have FIXME code around. > Hence, nf_nat_need_gre() and its calls have been removed. > > Signed-off-by: simran singhal

Re: [PATCH] net: ipv4: netfilter: Remove unused function nf_nat_need_gre()

On Sat, Apr 01, 2017 at 07:06:33PM +0530, simran singhal wrote: > The function nf_nat_need_gre() on being called, simply returns > back. The function doesn't have FIXME code around. > Hence, nf_nat_need_gre() and its calls have been removed. > > Signed-off-by: simran singhal > --- >

Re: [PATCH v4 2/2] iio: Aspeed ADC

On 04/06, Rick Altherr wrote: > On Wed, Apr 5, 2017 at 6:10 PM, Stephen Boyd wrote: > > On 04/05, Rick Altherr wrote: > >> On Wed, Apr 5, 2017 at 1:27 PM, Stephen Boyd wrote: > >> > On 03/23, Rick Altherr wrote: > >> >> + > >> >> +static int

Re: [PATCH v4 2/2] iio: Aspeed ADC

On 04/06, Rick Altherr wrote: > On Wed, Apr 5, 2017 at 6:10 PM, Stephen Boyd wrote: > > On 04/05, Rick Altherr wrote: > >> On Wed, Apr 5, 2017 at 1:27 PM, Stephen Boyd wrote: > >> > On 03/23, Rick Altherr wrote: > >> >> + > >> >> +static int aspeed_adc_probe(struct platform_device *pdev) > >> >>

<    1   2   3   4   5   6   7   8   9   10   >