Re: [PATCH] x86/kvm: disable fast MMIO when running nested

2018-01-24 23:12 GMT+08:00 Vitaly Kuznetsov : > I was investigating an issue with seabios >= 1.10 which stopped working > for nested KVM on Hyper-V. The problem appears to be in > handle_ept_violation() function: when we do fast mmio we need to skip > the instruction so we do

Re: [PATCH] x86/kvm: disable fast MMIO when running nested

2018-01-24 23:12 GMT+08:00 Vitaly Kuznetsov : > I was investigating an issue with seabios >= 1.10 which stopped working > for nested KVM on Hyper-V. The problem appears to be in > handle_ept_violation() function: when we do fast mmio we need to skip > the instruction so we do

Re: tip/master falls off NOP cliff with KPTI under KVM

On Wed, 2018-01-24 at 16:53 -0800, Dexuan-Linux Cui wrote: > On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David wrote: > > > > On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote: > > > > > > > > > Bisection points to > > > > > >

Re: tip/master falls off NOP cliff with KPTI under KVM

On Wed, 2018-01-24 at 16:53 -0800, Dexuan-Linux Cui wrote: > On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David wrote: > > > > On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote: > > > > > > > > > Bisection points to > > > > > > f3433c1010c6af61c9897f0f0447f81b991feac1 is the

Re: [PATCH 5/6] Documentation for Pmalloc

On 24/01/18 21:14, Ralph Campbell wrote: > 2 Minor typos inline below: thanks for proof-reading, will fix accordingly. -- igor

Re: [PATCH 5/6] Documentation for Pmalloc

On 24/01/18 21:14, Ralph Campbell wrote: > 2 Minor typos inline below: thanks for proof-reading, will fix accordingly. -- igor

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

On 2018/1/25 12:16, Al Viro wrote: On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote: I have checked the given call chain, and find that nvme_dev_disable in nvme_timeout calls mutex_lock that can sleep. Thus, I suppose this call chain is not in atomic context. ... or it is broken.

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

On 2018/1/25 12:16, Al Viro wrote: On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote: I have checked the given call chain, and find that nvme_dev_disable in nvme_timeout calls mutex_lock that can sleep. Thus, I suppose this call chain is not in atomic context. ... or it is broken.

Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg

On Thu, Jan 25, 2018 at 3:08 AM, Shakeel Butt wrote: > On Wed, Jan 24, 2018 at 3:12 AM, Amir Goldstein wrote: >> On Wed, Jan 24, 2018 at 12:34 PM, Jan Kara wrote: >>> On Mon 22-01-18 22:31:20, Amir Goldstein wrote: On Fri, Jan 19, 2018

Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg

On Thu, Jan 25, 2018 at 3:08 AM, Shakeel Butt wrote: > On Wed, Jan 24, 2018 at 3:12 AM, Amir Goldstein wrote: >> On Wed, Jan 24, 2018 at 12:34 PM, Jan Kara wrote: >>> On Mon 22-01-18 22:31:20, Amir Goldstein wrote: On Fri, Jan 19, 2018 at 5:02 PM, Shakeel Butt wrote: > On Wed, Nov

Re: [REGRESSION] (>= v4.12) IO w/dmcrypt causing audio underruns

On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote: > Hi Vito, > > 2018-01-17 23:48 GMT+01:00 : > > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote: > >> Hi Vito, > >> > >> 2017-12-01 22:33 GMT+01:00 : > >> > On

Re: [REGRESSION] (>= v4.12) IO w/dmcrypt causing audio underruns

On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote: > Hi Vito, > > 2018-01-17 23:48 GMT+01:00 : > > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote: > >> Hi Vito, > >> > >> 2017-12-01 22:33 GMT+01:00 : > >> > On Wed, Nov 29, 2017 at 10:39:19AM -0800,

Re: [PATCH] ARM: dts: use a correct at24 fallback for at91-nattis-2-natte-2

2018-01-24 23:12 GMT+01:00 Peter Rosin : > Hi Bartosz, > > On 2018-01-24 22:34, Bartosz Golaszewski wrote: >> We now require all at24 users to use the "atmel," fallback in >> device tree for different manufacturers. > > I think my patch [3/4] from about a week ago was just a tiny

Re: [PATCH] ARM: dts: use a correct at24 fallback for at91-nattis-2-natte-2

2018-01-24 23:12 GMT+01:00 Peter Rosin : > Hi Bartosz, > > On 2018-01-24 22:34, Bartosz Golaszewski wrote: >> We now require all at24 users to use the "atmel," fallback in >> device tree for different manufacturers. > > I think my patch [3/4] from about a week ago was just a tiny bit > better. >

Re: [PATCH v2 4/4] RISC-V: Move to the new generic IRQ handler

On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote: > The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch > code looked at the Kconfig entry for our first-level irqchip driver and > called into it directly. > > This patch uses the new 0generic IRQ handling

Re: [PATCH v2 4/4] RISC-V: Move to the new generic IRQ handler

On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote: > The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch > code looked at the Kconfig entry for our first-level irqchip driver and > called into it directly. > > This patch uses the new 0generic IRQ handling

Re: [PATCH v2 1/4] arm: Make set_handle_irq and handle_arch_irq generic

On Wed, Jan 24, 2018 at 07:07:53PM -0800, Palmer Dabbelt wrote: > It looks like this same irqchip registration mechanism has been copied > into a handful of ports, including aarch64 and openrisc. I want to use > this in the RISC-V port, so I thought it would be good to make this > generic

Re: [PATCH v2 1/4] arm: Make set_handle_irq and handle_arch_irq generic

On Wed, Jan 24, 2018 at 07:07:53PM -0800, Palmer Dabbelt wrote: > It looks like this same irqchip registration mechanism has been copied > into a handful of ports, including aarch64 and openrisc. I want to use > this in the RISC-V port, so I thought it would be good to make this > generic

Re: [PATCH v2 3/4] openrisc: Use the new MULTI_IRQ_HANDLER

On Wed, Jan 24, 2018 at 07:07:55PM -0800, Palmer Dabbelt wrote: > It appears that openrisc copied arm64's MULTI_IRQ_HANDLER code (which > came from arm). I wanted to make this generic so I could use it in the > RISC-V port. This patch converts the openrisc code to use the generic > version.

Re: [PATCH v2 3/4] openrisc: Use the new MULTI_IRQ_HANDLER

On Wed, Jan 24, 2018 at 07:07:55PM -0800, Palmer Dabbelt wrote: > It appears that openrisc copied arm64's MULTI_IRQ_HANDLER code (which > came from arm). I wanted to make this generic so I could use it in the > RISC-V port. This patch converts the openrisc code to use the generic > version.

Re: [PATCH v2 2/4] arm64: Use the new MULTI_IRQ_HANDLER

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v2 2/4] arm64: Use the new MULTI_IRQ_HANDLER

Looks good, Reviewed-by: Christoph Hellwig

[PATCH] media: leds: as3645a: Add CONFIG_OF support

From: Akash Gajjar Witth this changes, the driver builds with CONFIG_OF support Signed-off-by: Akash Gajjar --- drivers/media/i2c/as3645a.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/media/i2c/as3645a.c

[PATCH] media: leds: as3645a: Add CONFIG_OF support

From: Akash Gajjar Witth this changes, the driver builds with CONFIG_OF support Signed-off-by: Akash Gajjar --- drivers/media/i2c/as3645a.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c index af5db71..24233fa 100644 ---

[PATCH net-next] ptr_ring: fix integer overflow

We try to allocate one more entry for lockless peeking. The adding operation may overflow which causes zero to be passed to kmalloc(). In this case, it returns ZERO_SIZE_PTR without any notice by ptr ring. Try to do producing or consuming on such ring will lead NULL dereference. Fix this detect

[PATCH net-next] ptr_ring: fix integer overflow

We try to allocate one more entry for lockless peeking. The adding operation may overflow which causes zero to be passed to kmalloc(). In this case, it returns ZERO_SIZE_PTR without any notice by ptr ring. Try to do producing or consuming on such ring will lead NULL dereference. Fix this detect

Re: [PATCH RFC 01/16] prcu: Add PRCU implementation

On Wed, Jan 24, 2018 at 10:16:18PM -0800, Paul E. McKenney wrote: > On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote: > > From: Heng Zhang > > > > This RCU implementation (PRCU) is based on a fast consensus protocol > > published in the following paper: >

Re: [PATCH RFC 01/16] prcu: Add PRCU implementation

On Wed, Jan 24, 2018 at 10:16:18PM -0800, Paul E. McKenney wrote: > On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote: > > From: Heng Zhang > > > > This RCU implementation (PRCU) is based on a fast consensus protocol > > published in the following paper: > > > > Fast

[PATCH v2 2/2] free_pcppages_bulk: prefetch buddy while not holding lock

When a page is freed back to the global pool, its buddy will be checked to see if it's possible to do a merge. This requires accessing buddy's page structure and that access could take a long time if it's cache cold. This patch adds a prefetch to the to-be-freed page's buddy outside of zone->lock

[PATCH v2 2/2] free_pcppages_bulk: prefetch buddy while not holding lock

When a page is freed back to the global pool, its buddy will be checked to see if it's possible to do a merge. This requires accessing buddy's page structure and that access could take a long time if it's cache cold. This patch adds a prefetch to the to-be-freed page's buddy outside of zone->lock

linux-next: build failure after merge of the rdma tree

Hi all, After merging the rdma tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "init_rcu_head" [drivers/infiniband/ulp/srpt/ib_srpt.ko] undefined! Caused by commit a11253142e6d ("IB/srpt: Rework multi-channel support") I have used the rdma tree from

linux-next: build failure after merge of the rdma tree

Hi all, After merging the rdma tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "init_rcu_head" [drivers/infiniband/ulp/srpt/ib_srpt.ko] undefined! Caused by commit a11253142e6d ("IB/srpt: Rework multi-channel support") I have used the rdma tree from

[PATCH v2 1/2] free_pcppages_bulk: do not hold lock when picking pages to free

When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy, the zone->lock is held and then pages are chosen from PCP's migratetype list. While there is actually no need to do this 'choose part' under lock since it's PCP pages, the only CPU that can touch them is us and irq is also

[PATCH v2 1/2] free_pcppages_bulk: do not hold lock when picking pages to free

When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy, the zone->lock is held and then pages are chosen from PCP's migratetype list. While there is actually no need to do this 'choose part' under lock since it's PCP pages, the only CPU that can touch them is us and irq is also

Re: [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references

On 1/18/2018 4:01 PM, Dan Williams wrote: 'array_ptr' is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks via speculative execution). The 'array_ptr' implementation is expected to be safe for current generation cpus

Re: [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references

On 1/18/2018 4:01 PM, Dan Williams wrote: 'array_ptr' is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks via speculative execution). The 'array_ptr' implementation is expected to be safe for current generation cpus

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/24/18 22:48, Frank Rowand wrote: > On 01/21/18 06:31, Wolfram Sang wrote: >> From: Tyrel Datwyler >> >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications generated in response >> to

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/24/18 22:48, Frank Rowand wrote: > On 01/21/18 06:31, Wolfram Sang wrote: >> From: Tyrel Datwyler >> >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications generated in response >> to node/property manipulations. >> >>

[RFC PATCH V4 4/5] workqueue: convert ->nice to ->sched_attr

The new /sys interface like this: #cat /sys/devices/virtual/workqueue/writeback/sched_attr policy=0 prio=0 nice=0 # echo "policy=0 prio=0 nice=-1" > /sys/devices/virtual/workqueue/writeback/sched_attr # cat /sys/devices/virtual/workqueue/writeback/sched_attr

[RFC PATCH V4 4/5] workqueue: convert ->nice to ->sched_attr

The new /sys interface like this: #cat /sys/devices/virtual/workqueue/writeback/sched_attr policy=0 prio=0 nice=0 # echo "policy=0 prio=0 nice=-1" > /sys/devices/virtual/workqueue/writeback/sched_attr # cat /sys/devices/virtual/workqueue/writeback/sched_attr

[RFC PATCH V4 5/5] workqueue: introduce a way to set workqueue's scheduler

When pinning RT threads to specific cores using CPU affinity, the kworkers on the same CPU would starve, which may lead to some kind of priority inversion. In that case, the RT threads would also suffer high performance impact. The priority inversion looks like, CPU 0: libvirtd acquired

[RFC PATCH V4 5/5] workqueue: introduce a way to set workqueue's scheduler

When pinning RT threads to specific cores using CPU affinity, the kworkers on the same CPU would starve, which may lead to some kind of priority inversion. In that case, the RT threads would also suffer high performance impact. The priority inversion looks like, CPU 0: libvirtd acquired

[RFC PATCH V4 3/5] workqueue: rename unbound_attrs to attrs

Replace workqueue's unbound_attrs by attrs, so that both unbound or bound wq can use it. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo

[RFC PATCH V4 3/5] workqueue: rename unbound_attrs to attrs

Replace workqueue's unbound_attrs by attrs, so that both unbound or bound wq can use it. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: kernel test robot Cc: linux-kernel@vger.kernel.org ---

[RFC PATCH V4 1/5] workqueue: rename system workqueues

Rename system_wq's wq->name from "events" to "system_percpu", and similarly for the similarly named workqueues. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo

[RFC PATCH V4 1/5] workqueue: rename system workqueues

Rename system_wq's wq->name from "events" to "system_percpu", and similarly for the similarly named workqueues. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: linux-kernel@vger.kernel.org ---

[RFC PATCH V4 2/5] workqueue: expose attrs for system workqueues

Expose sched_attr for system workqueues, such as: # cat /sys/devices/virtual/workqueue/system_percpu/sched_attr policy=0 prio=0 nice=0 cat /sys/devices/virtual/workqueue/system_percpu_highpri/sched_attr policy=0 prio=0 nice=-20 Signed-off-by: Wen Yang

[RFC PATCH V4 2/5] workqueue: expose attrs for system workqueues

Expose sched_attr for system workqueues, such as: # cat /sys/devices/virtual/workqueue/system_percpu/sched_attr policy=0 prio=0 nice=0 cat /sys/devices/virtual/workqueue/system_percpu_highpri/sched_attr policy=0 prio=0 nice=-20 Signed-off-by: Wen Yang

[PATCH v3] f2fs: support inode creation time

This patch adds creation time field in inode layout to support showing kstat.btime in ->statx. Signed-off-by: Chao Yu --- v3: - fix address alignment isue. fs/f2fs/f2fs.h | 7 +++ fs/f2fs/file.c | 9 + fs/f2fs/inode.c | 16

[PATCH v3] f2fs: support inode creation time

This patch adds creation time field in inode layout to support showing kstat.btime in ->statx. Signed-off-by: Chao Yu --- v3: - fix address alignment isue. fs/f2fs/f2fs.h | 7 +++ fs/f2fs/file.c | 9 + fs/f2fs/inode.c | 16

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Steve, On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial >

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Steve, On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial >

Re: [PATCH v2] f2fs: support inode creation time

On 2018/1/24 22:59, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/1/24 13:38, Jaegeuk Kim wrote: >> On 01/22, Chao Yu wrote: >>> From: Chao Yu >>> >>> This patch adds creation time field in inode layout to support showing >>> kstat.btime in ->statx. >> >> Hi Chao, >> >> Could you

Re: [PATCH v2] f2fs: support inode creation time

On 2018/1/24 22:59, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/1/24 13:38, Jaegeuk Kim wrote: >> On 01/22, Chao Yu wrote: >>> From: Chao Yu >>> >>> This patch adds creation time field in inode layout to support showing >>> kstat.btime in ->statx. >> >> Hi Chao, >> >> Could you please check this

Re: backport Rewrite sync_core() to use IRET-to-self to stable kernels?

A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Jan 25, 2018 at

Re: backport Rewrite sync_core() to use IRET-to-self to stable kernels?

A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Jan 25, 2018 at

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent upstreaming of the refcount API

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial > work! > > Note

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial > work! > > Note

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/22/18 03:49, Wolfram Sang wrote: > Hi Frank, > >> Please go back and read the thread for version 1. Simply resubmitting a >> forward port is ignoring that whole conversation. >> >> There is a lot of good info in that thread. I certainly learned stuff in it. > > Yes, I did that and

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/22/18 03:49, Wolfram Sang wrote: > Hi Frank, > >> Please go back and read the thread for version 1. Simply resubmitting a >> forward port is ignoring that whole conversation. >> >> There is a lot of good info in that thread. I certainly learned stuff in it. > > Yes, I did that and

Re: [REGRESSION] (>= v4.12) IO w/dmcrypt causing audio underruns

On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote: > Hi Vito, > > 2018-01-17 23:48 GMT+01:00 : > > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote: > >> Hi Vito, > >> > >> 2017-12-01 22:33 GMT+01:00 : > >> > On

Re: [REGRESSION] (>= v4.12) IO w/dmcrypt causing audio underruns

On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote: > Hi Vito, > > 2018-01-17 23:48 GMT+01:00 : > > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote: > >> Hi Vito, > >> > >> 2017-12-01 22:33 GMT+01:00 : > >> > On Wed, Nov 29, 2017 at 10:39:19AM -0800,

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: net/tipc/socket.c between commit: ade994f4f6c8 ("net: annotate ->poll() instances") from the vfs tree and commit: 60c253069632 ("tipc: fix race between poll() and setsockopt()") from the net-next tree. I fixed

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: net/tipc/socket.c between commit: ade994f4f6c8 ("net: annotate ->poll() instances") from the vfs tree and commit: 60c253069632 ("tipc: fix race between poll() and setsockopt()") from the net-next tree. I fixed

Re: [PATCH RFC 09/16] prcu: Implement prcu_barrier() API

On Tue, Jan 23, 2018 at 03:59:34PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > This is PRCU's counterpart of RCU's rcu_barrier() API. > > Reviewed-by: Heng Zhang > Signed-off-by: Lihao Liang > --- >

Re: [PATCH RFC 09/16] prcu: Implement prcu_barrier() API

On Tue, Jan 23, 2018 at 03:59:34PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > This is PRCU's counterpart of RCU's rcu_barrier() API. > > Reviewed-by: Heng Zhang > Signed-off-by: Lihao Liang > --- > include/linux/prcu.h | 7 ++ > kernel/rcu/prcu.c| 63 >

Re: [PATCH RFC 07/16] prcu: Implement call_prcu() API

On Tue, Jan 23, 2018 at 03:59:32PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > This is PRCU's counterpart of RCU's call_rcu() API. > > Reviewed-by: Heng Zhang > Signed-off-by: Lihao Liang > --- >

Re: [PATCH RFC 06/16] rcuperf: Set gp_exp to true for tests to run

On Tue, Jan 23, 2018 at 03:59:31PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Signed-off-by: Lihao Liang > --- > kernel/rcu/rcuperf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/rcu/rcuperf.c

Re: [PATCH RFC 07/16] prcu: Implement call_prcu() API

On Tue, Jan 23, 2018 at 03:59:32PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > This is PRCU's counterpart of RCU's call_rcu() API. > > Reviewed-by: Heng Zhang > Signed-off-by: Lihao Liang > --- > include/linux/prcu.h | 25 > init/main.c | 2 ++ >

Re: [PATCH RFC 06/16] rcuperf: Set gp_exp to true for tests to run

On Tue, Jan 23, 2018 at 03:59:31PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Signed-off-by: Lihao Liang > --- > kernel/rcu/rcuperf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c > index

Re: [PATCH RFC 15/16] rcutorture: Add scripts to run experiments

On Tue, Jan 23, 2018 at 03:59:40PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Signed-off-by: Lihao Liang > --- > kvm.sh | 452 > + > run-rcuperf.sh | 26 The

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Dear Paul, > > This patch set implements a preemptive version of RCU (PRCU) based on the > following paper: > > Fast Consensus Using Bounded Staleness for Scalable Read-mostly

Re: [PATCH RFC 15/16] rcutorture: Add scripts to run experiments

On Tue, Jan 23, 2018 at 03:59:40PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Signed-off-by: Lihao Liang > --- > kvm.sh | 452 > + > run-rcuperf.sh | 26 The usual approach would be to add what you need to

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Dear Paul, > > This patch set implements a preemptive version of RCU (PRCU) based on the > following paper: > > Fast Consensus Using Bounded Staleness for Scalable Read-mostly > Synchronization. >

Re: [PATCH RFC 03/16] rcutorture: Add PRCU test config files

On Tue, Jan 23, 2018 at 03:59:28PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Use the same config files as TREE02, TREE03, TREE06, TREE07, and TREE09. > > Signed-off-by: Lihao Liang > --- >

Re: [PATCH RFC 03/16] rcutorture: Add PRCU test config files

On Tue, Jan 23, 2018 at 03:59:28PM +0800, liangli...@huawei.com wrote: > From: Lihao Liang > > Use the same config files as TREE02, TREE03, TREE06, TREE07, and TREE09. > > Signed-off-by: Lihao Liang > --- > .../selftests/rcutorture/configs/rcu/CFLIST| 5 >

Re: [PATCH RFC 01/16] prcu: Add PRCU implementation

On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote: > From: Heng Zhang > > This RCU implementation (PRCU) is based on a fast consensus protocol > published in the following paper: > > Fast Consensus Using Bounded Staleness for Scalable Read-mostly >

Re: [PATCH RFC 01/16] prcu: Add PRCU implementation

On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote: > From: Heng Zhang > > This RCU implementation (PRCU) is based on a fast consensus protocol > published in the following paper: > > Fast Consensus Using Bounded Staleness for Scalable Read-mostly > Synchronization. > Haibo

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

Hi Eric Thanks for you kindly response and suggestion. That's really appreciated. Jianchao On 01/25/2018 11:55 AM, Eric Dumazet wrote: > On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote: >> Hi Tariq >> >> On 01/22/2018 10:12 AM, jianchao.wang wrote: > On 19/01/2018 5:49 PM, Eric

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

Hi Eric Thanks for you kindly response and suggestion. That's really appreciated. Jianchao On 01/25/2018 11:55 AM, Eric Dumazet wrote: > On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote: >> Hi Tariq >> >> On 01/22/2018 10:12 AM, jianchao.wang wrote: > On 19/01/2018 5:49 PM, Eric

Re: [PATCH] powerpc: pseries: use irq_of_parse_and_map helper

Rob Herring writes: > On Tue, Jan 23, 2018 at 12:53 AM, Michael Ellerman > wrote: >> Rob Herring writes: >> >>> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call >>> of_irq_parse_and_map instead which does the same

Re: [PATCH] powerpc: pseries: use irq_of_parse_and_map helper

Rob Herring writes: > On Tue, Jan 23, 2018 at 12:53 AM, Michael Ellerman > wrote: >> Rob Herring writes: >> >>> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call >>> of_irq_parse_and_map instead which does the same thing. This gets us closer >>> to making the former 2

linux-next: build failure after merge of the pci tree

Hi Bjorn, After merging the pci tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/pci-common.c: In function 'pcibios_setup _device': arch/powerpc/kernel/pci-common.c:406:15: error: 'virq' may be used uninitialized in this function

linux-next: build failure after merge of the pci tree

Hi Bjorn, After merging the pci tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/pci-common.c: In function 'pcibios_setup _device': arch/powerpc/kernel/pci-common.c:406:15: error: 'virq' may be used uninitialized in this function

[PATCH 8/8] kprobes/s390: Fix %p uses in error messages

Remove %p because the kprobe will be dumped in dump_kprobe(). Signed-off-by: Masami Hiramatsu --- arch/s390/kernel/kprobes.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c index

[PATCH 8/8] kprobes/s390: Fix %p uses in error messages

Remove %p because the kprobe will be dumped in dump_kprobe(). Signed-off-by: Masami Hiramatsu --- arch/s390/kernel/kprobes.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c index af3722c28fd9..df30e5b9a572 100644 ---

[PATCH 6/8] kprobes/arm64: Fix %p uses in error messages

Fix %p uses in error messages by removing it because those are redundant or meaningless. Signed-off-by: Masami Hiramatsu --- arch/arm64/kernel/probes/kprobes.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/probes/kprobes.c

[PATCH 6/8] kprobes/arm64: Fix %p uses in error messages

Fix %p uses in error messages by removing it because those are redundant or meaningless. Signed-off-by: Masami Hiramatsu --- arch/arm64/kernel/probes/kprobes.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/probes/kprobes.c

[PATCH 7/8] kprobes/MN10300: Fix %p uses in error messages

Replace %p with %px because it is right before BUG(). Signed-off-by: Masami Hiramatsu --- arch/mn10300/kernel/kprobes.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mn10300/kernel/kprobes.c b/arch/mn10300/kernel/kprobes.c index

[PATCH 7/8] kprobes/MN10300: Fix %p uses in error messages

Replace %p with %px because it is right before BUG(). Signed-off-by: Masami Hiramatsu --- arch/mn10300/kernel/kprobes.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mn10300/kernel/kprobes.c b/arch/mn10300/kernel/kprobes.c index 0311a7fcea16..e539fac00321

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

On Wed, Jan 24, 2018 at 08:34:14PM -0700, Jens Axboe wrote: > On 1/24/18 7:46 PM, Jia-Ju Bai wrote: > > The function ioc_create_icq here is not called in atomic context. > > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. > > > > This is found by a static analysis tool

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

On Wed, Jan 24, 2018 at 08:34:14PM -0700, Jens Axboe wrote: > On 1/24/18 7:46 PM, Jia-Ju Bai wrote: > > The function ioc_create_icq here is not called in atomic context. > > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. > > > > This is found by a static analysis tool

[PATCH 5/8] kprobes/arm: Fix %p uses in error messages

Fix %p uses in error messages by removing it and using general dumper. Signed-off-by: Masami Hiramatsu --- arch/arm/probes/kprobes/core.c | 10 +- arch/arm/probes/kprobes/test-core.c |1 - 2 files changed, 5 insertions(+), 6 deletions(-) diff --git

[PATCH 5/8] kprobes/arm: Fix %p uses in error messages

Fix %p uses in error messages by removing it and using general dumper. Signed-off-by: Masami Hiramatsu --- arch/arm/probes/kprobes/core.c | 10 +- arch/arm/probes/kprobes/test-core.c |1 - 2 files changed, 5 insertions(+), 6 deletions(-) diff --git

[PATCH 4/8] kprobes/x86: Fix %p uses in error messages

Fix %p uses in error messages in kprobes/x86. - Some %p uses are not needed. Just remove it (or remove message). - One %p use is right before the BUG() so replaced with %px. Signed-off-by: Masami Hiramatsu --- arch/x86/kernel/kprobes/core.c | 12 1 file

Hello Linux

good morning Linux https://goo.gl/2YZCS5

[PATCH 4/8] kprobes/x86: Fix %p uses in error messages

Fix %p uses in error messages in kprobes/x86. - Some %p uses are not needed. Just remove it (or remove message). - One %p use is right before the BUG() so replaced with %px. Signed-off-by: Masami Hiramatsu --- arch/x86/kernel/kprobes/core.c | 12 1 file changed, 4 insertions(+),

Hello Linux

good morning Linux https://goo.gl/2YZCS5

  1   2   3   4   5   6   7   8   9   10   >