[RFC v7 04/19] lockdep: Make __bfs() visit every dependency until a match

ks in mark_lock_accessed() and lock_accessed() are removed, because after this modification, we may call these two functions on @source_entry of __bfs(), which may not be the entry in "list_entries" Signed-off-by: Boqun Feng --- kernel/locking/lockdep.c | 61 +++--

[RFC v7 03/19] lockdep: Demagic the return value of BFS

for the return value of __bfs() and its friends, this improves the code readability of the code, and further, could help if we want to extend the BFS. Signed-off-by: Boqun Feng --- kernel/locking/lockdep.c | 155 ++- 1 file changed, 89 insertions(+), 66 deletions

[RFC v7 05/19] lockdep: Reduce the size of lock_list::distance

structure. Suggested-by: Peter Zijlstra Signed-off-by: Boqun Feng --- include/linux/lockdep.h | 2 +- kernel/locking/lockdep.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h index 6b7cb390f19f..b85973515f84 100644

[RFC v7 02/19] lockdep/Documention: Recursive read lock detection reasoning

types of dependencies, and the definition of strong paths. * Proof for a closed strong path is both sufficient and necessary for deadlock detections with recursive read locks involved. The proof could also explain why we call the path "strong" Signed-off-by:

[RFC v7 00/19] lockdep: Support deadlock detection for recursive read locks

Hi Peter and Waiman, As promised, this is the updated version of my previous lockdep patchset for recursive read lock support. It's based on v5.8. Previous versions can be found at: V1: https://marc.info/?l=linux-kernel=150393341825453 V2: https://marc.info/?l=linux-kernel=150468649417950 V3:

[RFC v7 01/19] locking: More accurate annotations for read_lock()

, and this is useful, especially for the lockdep development selftest, so we keep this via a variable to force switching lock annotation for read_lock(). Signed-off-by: Boqun Feng --- include/linux/lockdep.h | 23 ++- kernel/locking/lockdep.c | 14 ++ lib/locking

Re: [PATCH 2/2 v2] rseq/selftests: test MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU

On Thu, Aug 06, 2020 at 10:05:44AM -0700, Peter Oskolkov wrote: > Based on Google-internal RSEQ work done by > Paul Turner and Andrew Hunter. > > This patch adds a selftest for MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU. > The test quite often fails without the previous patch in this patchset, >

Re: [PATCH RFC v2] rcu/segcblist: Add counters to segcblist datastructure

On Mon, Jul 27, 2020 at 07:03:23PM -0400, Joel Fernandes wrote: > On Mon, Jul 27, 2020 at 09:49:25PM +0800, Boqun Feng wrote: > [...] > > So C11 features are available to gnu89 as extensions, also I tried to > > compile the following code with -std=gnu89: >

Re: [PATCH RFC v2] rcu/segcblist: Add counters to segcblist datastructure

On Fri, Jul 24, 2020 at 03:34:46PM -0400, Joel Fernandes wrote: > On Mon, Jul 20, 2020 at 4:22 AM wrote: > > > > Hi Joel, > > Sorry for the late reply as I was on vacation last several days. > > > > > On Sun, Jul 19, 2020 at 12:18:41AM -0400, Joel Fernandes wrote: > > > On Sun, Jul 19, 2020 at

Re: [RFC 11/11] scsi: storvsc: Support PAGE_SIZE larger than 4K

On Thu, Jul 23, 2020 at 02:26:00AM +, Michael Kelley wrote: > From: boqun.f...@gmail.com Sent: Wednesday, July 22, > 2020 6:52 PM > > > > On Thu, Jul 23, 2020 at 12:13:07AM +, Michael Kelley wrote: > > > From: Boqun Feng Sent: Monday, July 20, 2020 6:42 >

Re: [RFC 11/11] scsi: storvsc: Support PAGE_SIZE larger than 4K

On Thu, Jul 23, 2020 at 12:13:07AM +, Michael Kelley wrote: > From: Boqun Feng Sent: Monday, July 20, 2020 6:42 PM > > > > Hyper-V always use 4k page size (HV_HYP_PAGE_SIZE), so when > > communicating with Hyper-V, a guest should always use HV_HYP_PAGE_SIZE > > a

Re: [RFC 09/11] HID: hyperv: Make ringbuffer at least take two pages

On Wed, Jul 22, 2020 at 11:36:15PM +, Michael Kelley wrote: > From: Boqun Feng Sent: Monday, July 20, 2020 6:42 PM > > > > When PAGE_SIZE > HV_HYP_PAGE_SIZE, we need the ringbuffer size to be at > > least 2 * PAGE_SIZE: one page for the header and at least one p

Re: [RFC 03/11] Drivers: hv: vmbus: Introduce types of GPADL

On Wed, Jul 22, 2020 at 11:25:18PM +, Michael Kelley wrote: > From: Boqun Feng Sent: Monday, July 20, 2020 6:41 PM > > > > This patch introduces two types of GPADL: HV_GPADL_{BUFFER, RING}. The > > types of GPADL are purely the concept in the guest, IOW the hype

Re: [RFC 01/11] Drivers: hv: vmbus: Always use HV_HYP_PAGE_SIZE for gpadl

On Tue, Jul 21, 2020 at 03:22:18PM +, Wei Liu wrote: > On Tue, Jul 21, 2020 at 09:41:25AM +0800, Boqun Feng wrote: > > Since the hypervisor always uses 4K as its page size, the size of PFNs > > used for gpadl should be HV_HYP_PAGE_SIZE rather than PAGE_SIZE, so > > ad

[RFC 03/11] Drivers: hv: vmbus: Introduce types of GPADL

le this special case, we need the types of GPADL to differ different guest memory usage for GPADL. Type enum is introduced along with several general interfaces to describe the differences between normal buffer GPADL and ringbuffer GPADL. Signed-off-by: Boqun Feng --- drivers/

[RFC 08/11] Input: hyperv-keyboard: Make ringbuffer at least take two pages

ing vmbus_open() to establish the vmbus connection. Signed-off-by: Boqun Feng --- drivers/input/serio/hyperv-keyboard.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/serio/hyperv-keyboard.c b/drivers/input/serio/hyperv-keyboard.c index df4e9f6f4529..77ba57ba2

[RFC 04/11] Drivers: hv: Use HV_HYP_PAGE in hv_synic_enable_regs()

Both the base_*_gpa should use the guest page number in Hyper-V page, so use HV_HYP_PAGE instead of PAGE. Signed-off-by: Boqun Feng --- drivers/hv/hv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c index 41b2ee06cc2f..e4f50dcdc46c

[RFC 06/11] hv: hyperv.h: Introduce some hvpfn helper functions

When a guest communicate with the hypervisor, it must use HV_HYP_PAGE to calculate PFN, so introduce a few hvpfn helper functions as the counterpart of the page helper functions. This is the preparation for supporting guest whose PAGE_SIZE is not 4k. Signed-off-by: Boqun Feng --- include/linux

[RFC 01/11] Drivers: hv: vmbus: Always use HV_HYP_PAGE_SIZE for gpadl

Since the hypervisor always uses 4K as its page size, the size of PFNs used for gpadl should be HV_HYP_PAGE_SIZE rather than PAGE_SIZE, so adjust this accordingly as the preparation for supporting 16K/64K page size guests. Signed-off-by: Boqun Feng --- drivers/hv/channel.c | 13 + 1

[RFC 05/11] Drivers: hv: vmbus: Move virt_to_hvpfn() to hyperv header

There will be more places other than vmbus where we need to calculate the Hyper-V page PFN from a virtual address, so move virt_to_hvpfn() to hyperv generic header. Signed-off-by: Boqun Feng --- drivers/hv/channel.c | 13 - include/linux/hyperv.h | 15 +++ 2 files

[RFC 02/11] Drivers: hv: vmbus: Move __vmbus_open()

Pure function movement, no functional changes. The move is made, because in a later change, __vmbus_open() will rely on some static functions afterwards, so we sperate the move and the modification of __vmbus_open() in two patches to make it easy to review. Signed-off-by: Boqun Feng --- drivers

[RFC 09/11] HID: hyperv: Make ringbuffer at least take two pages

ing vmbus_open() to establish the vmbus connection. Signed-off-by: Boqun Feng --- drivers/hid/hid-hyperv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c index 0b6ee1dee625..36c5e157c691 100644 --- a/drivers/hid/hid-hyperv.c ++

[RFC 07/11] hv_netvsc: Use HV_HYP_PAGE_SIZE for Hyper-V communication

In order to support guest whose page size is not 4k, we need to make hv_netvsc always use HV_HYP_PAGE_SIZE for Hyper-V communication. Signed-off-by: Boqun Feng --- drivers/net/hyperv/netvsc.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 46 +++ drivers/

[RFC 10/11] Driver: hv: util: Make ringbuffer at least take two pages

ing vmbus_open() to establish the vmbus connection. Signed-off-by: Boqun Feng --- drivers/hv/hv_util.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c index 92ee0fe4c919..73a77bead2be 100644 --- a/drivers/hv/hv_util.c ++

[RFC 11/11] scsi: storvsc: Support PAGE_SIZE larger than 4K

convert pages in the sglist of scsi_cmnd into Hyper-V pages in vmbus_packet_mpb_array. This patch does the conversion by dividing pages in sglist into Hyper-V pages, offset and indexes in vmbus_packet_mpb_array are recalculated accordingly. Signed-off-by: Boqun Feng --- drivers/scsi/storvsc_drv.c

[RFC 00/11] Hyper-V: Support PAGE_SIZE larger than 4K

;-) (I could observe an error caused by unaligned firmware data, but it's better to have it fixed in the Hyper-V). Looking forwards to comments and suggestions! Regards, Boqun [1]: https://lore.kernel.org/lkml/1584200119-18594-1-git-send-email-mikel...@microsoft.com/ Boqun Feng (11): Drivers: h

Re: [PATCH RFC v2] rcu/segcblist: Add counters to segcblist datastructure

Hi Joel, On Sun, Jul 19, 2020 at 12:18:41AM -0400, Joel Fernandes wrote: > On Sun, Jul 19, 2020 at 12:06:28AM -0400, Joel Fernandes wrote: > > On Sat, Jul 18, 2020 at 11:55 PM Joel Fernandes (Google) > > wrote: > > [...] > > > /* If no callbacks moved, nothing more need be done. */ > > >

Re: [PATCH v3 02/19] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h

On Fri, Jul 10, 2020 at 05:51:46PM +0100, Will Deacon wrote: > In preparation for allowing architectures to define their own > implementation of the READ_ONCE() macro, move the generic > {READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h' > file and into a new 'rwonce.h' header

Re: possible deadlock in send_sigio

Hi Matthew, On Mon, Jun 15, 2020 at 01:40:46PM -0700, Matthew Wilcox wrote: > On Mon, Jun 15, 2020 at 01:13:51PM -0400, Waiman Long wrote: > > On 6/15/20 12:49 PM, Matthew Wilcox wrote: > > > On Fri, Jun 12, 2020 at 03:01:01PM +0800, Boqun Feng wrote: > > > > On

Re: possible deadlock in send_sigio

On Fri, Jun 12, 2020 at 07:55:26AM +0800, Boqun Feng wrote: > Hi Peter and Waiman, > > On Thu, Jun 11, 2020 at 12:09:59PM -0400, Waiman Long wrote: > > On 6/11/20 10:22 AM, Peter Zijlstra wrote: > > > On Thu, Jun 11, 2020 at 09:51:29AM -0400, Waiman Long wrote: > &g

Re: possible deadlock in send_sigio

Hi Peter and Waiman, On Thu, Jun 11, 2020 at 12:09:59PM -0400, Waiman Long wrote: > On 6/11/20 10:22 AM, Peter Zijlstra wrote: > > On Thu, Jun 11, 2020 at 09:51:29AM -0400, Waiman Long wrote: > > > > > There was an old lockdep patch that I think may address the issue, but was > > > not merged at

Re: [patch V9 30/39] x86/entry: Convert various hypervisor vectors to IDTENTRY_SYSVEC

On Wed, May 27, 2020 at 12:09:18PM +, Wei Liu wrote: > On Wed, May 27, 2020 at 09:38:03AM +0100, Wei Liu wrote: > > On Wed, May 27, 2020 at 09:46:16AM +0800, Boqun Feng wrote: > > > Hi Thomas, > > > > > > On Thu, May 21, 2020 at 10:05:43PM +0200, Thomas

Re: Some -serious- BPF-related litmus tests

Hi Andrii, On Fri, May 22, 2020 at 12:38:21PM -0700, Andrii Nakryiko wrote: > On 5/22/20 10:43 AM, Paul E. McKenney wrote: > > On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote: > > > On Fri, May 22, 2020 at 11:44:07AM +0200, Peter Zijlstra wrote: > > > > On Thu, May 21, 2020 at

Re: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one

: Akira Yokosawa > Acked-by: Andrea Parri > Acked-by: Joel Fernandes (Google) Acked-by: Boqun Feng Thanks! Regards, Boqun > --- > Documentation/litmus-tests/README| 19 +++ > Documentation/litmus-tests/atomic/README | 16 > 2 files cha

Re: [PATCH] rcu: Avoid to modify mask_ofl_ipi in sync_rcu_exp_select_node_cpus()

On Tue, Oct 08, 2019 at 01:01:21PM -0400, Joel Fernandes wrote: > On Tue, Oct 08, 2019 at 06:35:45PM +0200, Marco Elver wrote: > > On Tue, 8 Oct 2019 at 18:30, Joel Fernandes wrote: > > > > > > On Tue, Oct 08, 2019 at 01:01:40PM +0800, Boqun Feng wrote: > > >

[PATCH] rcu: Avoid to modify mask_ofl_ipi in sync_rcu_exp_select_node_cpus()

de_cpus(). Two variables seems to be redundant for such a propose, so this patch clean things a little by solely using "mask_ofl_test" for recording and "mask_ofl_ipi" for iteration. This would improve the readibility of the IPI sending loop in sync_rcu_exp_select_node_c

Re: Kernel Concurrency Sanitizer (KCSAN)

On Mon, Sep 23, 2019 at 01:01:27PM +0200, Marco Elver wrote: > On Mon, 23 Sep 2019 at 10:59, Dmitry Vyukov wrote: > > > > On Mon, Sep 23, 2019 at 10:54 AM Boqun Feng wrote: > > > > > > On Mon, Sep 23, 2019 at 10:21:38AM +0200, Dmitry Vyukov wrote: > > &g

Re: Kernel Concurrency Sanitizer (KCSAN)

On Mon, Sep 23, 2019 at 10:21:38AM +0200, Dmitry Vyukov wrote: > On Mon, Sep 23, 2019 at 6:31 AM Boqun Feng wrote: > > > > On Fri, Sep 20, 2019 at 04:54:21PM +0100, Will Deacon wrote: > > > Hi Marco, > > > > > > On Fri, Sep 20, 2019 at 04:18:57PM +0200

Re: Kernel Concurrency Sanitizer (KCSAN)

On Fri, Sep 20, 2019 at 04:54:21PM +0100, Will Deacon wrote: > Hi Marco, > > On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote: > > We would like to share a new data-race detector for the Linux kernel: > > Kernel Concurrency Sanitizer (KCSAN) -- > >

Re: Documentation for plain accesses and data races

On Mon, Sep 16, 2019 at 11:22:18AM -0400, Alan Stern wrote: > On Mon, 16 Sep 2019, Boqun Feng wrote: > > > > executes if Y is a store.) This is expressed by the visibility > > > relation (vis), where X ->vis Y is defined to hold if there is an

Re: Documentation for plain accesses and data races

On Mon, Sep 16, 2019 at 01:17:53PM +0800, Boqun Feng wrote: > Hi Alan, > > I spend some time reading this, really helpful! Thanks. > > Please see comments below: > > On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote: > [...] > > If two memory accesses a

Re: Documentation for plain accesses and data races

Hi Alan, I spend some time reading this, really helpful! Thanks. Please see comments below: On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote: [...] > If two memory accesses aren't concurrent then one must execute before > the other. Therefore the LKMM decides two accesses aren't

Re: [PATCH] locking/percpu_rwsem: Rewrite to not use rwsem

On Mon, Aug 05, 2019 at 05:43:28PM +0200, Peter Zijlstra wrote: > On Mon, Aug 05, 2019 at 10:58:13PM +0800, Boqun Feng wrote: > > On Mon, Aug 05, 2019 at 10:43:18PM +0800, Boqun Feng wrote: > > > On Mon, Aug 05, 2019 at 04:02:41PM +0200, Peter Zijlstra wrote: > > > [...

Re: [PATCH] locking/percpu_rwsem: Rewrite to not use rwsem

On Mon, Aug 05, 2019 at 10:43:18PM +0800, Boqun Feng wrote: > On Mon, Aug 05, 2019 at 04:02:41PM +0200, Peter Zijlstra wrote: > [...] > > > > static inline void percpu_up_read(struct percpu_rw_semaphore *sem) > > { > > + rwsem_release(>dep_map, 1, _RET_IP

Re: [PATCH] locking/percpu_rwsem: Rewrite to not use rwsem

On Mon, Aug 05, 2019 at 04:02:41PM +0200, Peter Zijlstra wrote: [...] > > static inline void percpu_up_read(struct percpu_rw_semaphore *sem) > { > + rwsem_release(>dep_map, 1, _RET_IP_); > + > preempt_disable(); > /* >* Same as in percpu_down_read(). >*/ > -

Re: [PATCH v2] lkmm/docs: Correct ->prop example with additional rfe link

On Sun, Jul 28, 2019 at 11:35:44AM -0400, Joel Fernandes wrote: [...] > > > > > +load of y (rfe link), P2's smp_store_release() ensures that P2's load > > > > > +of y executes before P2's store to z (second fence), which implies > > > > > that > > > > > +that stores to x and y propagate to P2

Re: [PATCH v2] lkmm/docs: Correct ->prop example with additional rfe link

->prop ordering on P0 more clear. > > > > > > Cc: kernel-t...@android.com > > > Reviewed-by: Boqun Feng > > > Signed-off-by: Joel Fernandes (Google) > > > --- > > > > This is not a good update. See below... > > No problem, tha

Re: [PATCH] docs/lkmm: Correct ->prop example with additional rfe link

e propagation ordering that smp_store_release() guarantees only works with stores that already propagated to the CPU executing it, not the stores that execute/happen before. With that, feel free to add: Reviewed-by: Boqun Feng Regards, Boqun > +means that P2's smp_store_release() will propagate s

Re: [PATCH v3 30/30] locking/lockdep: Remove irq-safe to irq-unsafe read check

On Fri, Jun 28, 2019 at 05:15:28PM +0800, Yuyang Du wrote: > We have a lockdep warning: > > > WARNING: possible irq lock inversion dependency detected > 5.1.0-rc7+ #141 Not tainted >

Re: [PATCH v3 17/30] locking/lockdep: Add read-write type for a lock dependency

On Fri, Jun 28, 2019 at 05:15:15PM +0800, Yuyang Du wrote: > Direct dependencies need to keep track of their read-write lock types. > Two bit fields, which share the distance field, are added to lock_list > struct so the types are stored there. > > With a dependecy lock1 -> lock2, lock_type1 has

Re: [PATCH v8 07/19] locking/rwsem: Implement lock handoff to prevent lock starvation

On Tue, Jun 04, 2019 at 11:26:30AM +0800, Yuyang Du wrote: > On Tue, 4 Jun 2019 at 11:03, Yuyang Du wrote: > > > > Hi Waiman, > > > > On Tue, 21 May 2019 at 05:01, Waiman Long wrote: > > > > > > Because of writer lock stealing, it is possible that a constant > > > stream of incoming writers will

Re: rcu_read_lock lost its compiler barrier

On Mon, Jun 03, 2019 at 01:26:26PM +0800, Herbert Xu wrote: > On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote: > > > > 1. These guarantees are of full memory barriers, -not- compiler > > barriers. > > What I'm saying is that wherever they are, they must come with > compiler

Re: [PATCH v2 11/17] locking/lockdep: Adjust lockdep selftest cases

On Thu, May 16, 2019 at 04:00:09PM +0800, Yuyang Du wrote: > With read-write lock support, some read-write lock cases need to be updated, > specifically, some read-lock involved deadlocks are actually not deadlocks. > Hope I am not wildly wrong. > > Signed-off-by: Yuyang Du > --- >

Re: [PATCH v2 02/17] locking/lockdep: Add read-write type for dependency

On Thu, May 16, 2019 at 04:00:00PM +0800, Yuyang Du wrote: > Direct dependency needs to keep track of its locks' read-write types. A > union field is added to lock_list struct so the type is stored there as > this: > > lock_type[1] (u16), lock_type[0] (u16) > > or: >

Re: [PATCH 24/28] locking/lockdep: Remove !dir in lock irq usage check

On Fri, Apr 26, 2019, at 3:06 PM, Yuyang Du wrote: > Thanks for review. > > On Fri, 26 Apr 2019 at 04:03, Peter Zijlstra wrote: > > > > On Wed, Apr 24, 2019 at 06:19:30PM +0800, Yuyang Du wrote: > > > In mark_lock_irq(), the following checks are performed: > > > > > >

Re: [PATCH] Documentation/atomic_t: Clarify signed vs unsigned

On Mon, Feb 11, 2019 at 06:09:43PM +0100, Peter Zijlstra wrote: > > Clarify the whole signed vs unsigned issue for atomic_t. > > There has been enough confusion on this topic to warrant a few explicit > words I feel. > > Signed-off-by: Peter Zijlstra (Intel) FWIW

Re: [PATCH] srcu: Remove srcu_queue_delayed_work_on()

Hi Joel, On Tue, Dec 11, 2018 at 05:40:16PM -0800, Joel Fernandes wrote: > On Tue, Dec 11, 2018 at 12:12:38PM +0100, Sebastian Andrzej Siewior wrote: > > srcu_queue_delayed_work_on() disables preemption (and therefore CPU > > hotplug in RCU's case) and then checks based on its own accounting if a

Re: [PATCH 2/3] tools/memory-model: Refactor some RCU relations

Hi Alan, On Thu, Nov 15, 2018 at 11:19:58AM -0500, Alan Stern wrote: > In preparation for adding support for SRCU, refactor the definitions > of rcu-fence, rcu-rscsi, rcu-link, and rb by moving the po and po? > terms from the first two to the second two. An rcu-gp relation is > added; it is

Re: [PATCH 2/3] tools/memory-model: Refactor some RCU relations

Hi Alan, On Thu, Nov 15, 2018 at 11:19:58AM -0500, Alan Stern wrote: > In preparation for adding support for SRCU, refactor the definitions > of rcu-fence, rcu-rscsi, rcu-link, and rb by moving the po and po? > terms from the first two to the second two. An rcu-gp relation is > added; it is

Re: [PATCH] rcu: Use cpus_read_lock() while looking at cpu_online_mask

On Mon, Oct 15, 2018 at 05:09:03PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-10-15 23:07:15 [+0800], Boqun Feng wrote: > > Hi, Sebastian > Hi Boqun, > > > On Mon, Oct 15, 2018 at 04:42:17PM +0200, Sebastian Andrzej Siewior wrote: > > > On 2018-10-13 06:4

Re: [PATCH] rcu: Use cpus_read_lock() while looking at cpu_online_mask

On Mon, Oct 15, 2018 at 05:09:03PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-10-15 23:07:15 [+0800], Boqun Feng wrote: > > Hi, Sebastian > Hi Boqun, > > > On Mon, Oct 15, 2018 at 04:42:17PM +0200, Sebastian Andrzej Siewior wrote: > > > On 2018-10-13 06:4

Re: [PATCH] rcu: Use cpus_read_lock() while looking at cpu_online_mask

Hi, Sebastian On Mon, Oct 15, 2018 at 04:42:17PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-10-13 06:48:13 [-0700], Paul E. McKenney wrote: > > > > My concern would be that it would queue it by default for the current > > CPU, which would serialize the processing, losing the concurrency

Re: [PATCH] rcu: Use cpus_read_lock() while looking at cpu_online_mask

Hi, Sebastian On Mon, Oct 15, 2018 at 04:42:17PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-10-13 06:48:13 [-0700], Paul E. McKenney wrote: > > > > My concern would be that it would queue it by default for the current > > CPU, which would serialize the processing, losing the concurrency

Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline

On Tue, Jun 26, 2018 at 12:27:47PM -0700, Paul E. McKenney wrote: > On Tue, Jun 26, 2018 at 07:46:52PM +0800, Boqun Feng wrote: > > On Tue, Jun 26, 2018 at 06:44:47PM +0800, Boqun Feng wrote: > > > On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote: > > > &

Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline

On Tue, Jun 26, 2018 at 12:27:47PM -0700, Paul E. McKenney wrote: > On Tue, Jun 26, 2018 at 07:46:52PM +0800, Boqun Feng wrote: > > On Tue, Jun 26, 2018 at 06:44:47PM +0800, Boqun Feng wrote: > > > On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote: > > > &

Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline

On Tue, Jun 26, 2018 at 06:44:47PM +0800, Boqun Feng wrote: > On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote: > > On Mon, Jun 25, 2018 at 03:43:32PM -0700, Paul E. McKenney wrote: > > > + preempt_disable(); > > > + for_each_leaf

Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline

On Tue, Jun 26, 2018 at 06:44:47PM +0800, Boqun Feng wrote: > On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote: > > On Mon, Jun 25, 2018 at 03:43:32PM -0700, Paul E. McKenney wrote: > > > + preempt_disable(); > > > + for_each_leaf

Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline

On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote: > On Mon, Jun 25, 2018 at 03:43:32PM -0700, Paul E. McKenney wrote: > > + preempt_disable(); > > + for_each_leaf_node_possible_cpu(rnp, cpu) { > > + if (cpu_is_offline(cpu)) /* Preemption

Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline

On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote: > On Mon, Jun 25, 2018 at 03:43:32PM -0700, Paul E. McKenney wrote: > > + preempt_disable(); > > + for_each_leaf_node_possible_cpu(rnp, cpu) { > > + if (cpu_is_offline(cpu)) /* Preemption

Re: write_lock_irq(_lock)

treat read_lock() as pure recursive read locks in lib/locking-seftest.c, and this is useful, especially for the lockdep development selftest, so we keep this via a variable to force switching lock annotation for read_lock(). Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- include/linux/lo

Re: write_lock_irq(_lock)

ead locks in lib/locking-seftest.c, and this is useful, especially for the lockdep development selftest, so we keep this via a variable to force switching lock annotation for read_lock(). Signed-off-by: Boqun Feng --- include/linux/lockdep.h | 35 ++- lib/locking-

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Fri, May 18, 2018 at 02:17:17PM -0400, Mathieu Desnoyers wrote: > - On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote: > [...] > >> > I think you're right. So we have to introduce callsite to rseq_syscall() > >> > in syscall path, something l

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Fri, May 18, 2018 at 02:17:17PM -0400, Mathieu Desnoyers wrote: > - On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote: > [...] > >> > I think you're right. So we have to introduce callsite to rseq_syscall() > >> > in syscall path, something l

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Thu, May 17, 2018, at 11:28 PM, Mathieu Desnoyers wrote: > - On May 16, 2018, at 9:19 PM, Boqun Feng boqun.f...@gmail.com wrote: > > > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > >> - On May 16, 2018, at 12:18 PM, Peter Zijlstra

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Thu, May 17, 2018, at 11:28 PM, Mathieu Desnoyers wrote: > - On May 16, 2018, at 9:19 PM, Boqun Feng boqun.f...@gmail.com wrote: > > > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > >> - On May 16, 2018, at 12:18 PM, Peter Zijlstra

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > - On May 16, 2018, at 12:18 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Mon, Apr 30, 2018 at 06:44:26PM -0400, Mathieu Desnoyers wrote: > >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > >> index

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > - On May 16, 2018, at 12:18 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Mon, Apr 30, 2018 at 06:44:26PM -0400, Mathieu Desnoyers wrote: > >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > >> index

[PATCH v2] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

. No change in functionality or code generation. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Mark Rutland <mark.rutl...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de&g

[PATCH v2] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

. No change in functionality or code generation. Signed-off-by: Boqun Feng Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: aryabi...@virtuozzo.com Cc: catalin.mari...@arm.com Cc: dvyu...@google.com Cc: linux-arm-ker...@lists.infradead.org Cc: will.dea...@arm.com

Re: [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

On Sun, May 6, 2018, at 8:11 PM, Ingo Molnar wrote: > > * Boqun Feng <boqun.f...@gmail.com> wrote: > > > > The only change I made beyond a trivial build fix is that I also added > > > the release > > > atomics variants explicitly: > >

Re: [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

On Sun, May 6, 2018, at 8:11 PM, Ingo Molnar wrote: > > * Boqun Feng wrote: > > > > The only change I made beyond a trivial build fix is that I also added > > > the release > > > atomics variants explicitly: > > > > > > +#define ato

[tip:locking/core] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

Commit-ID: 0476a632cb3aa88c03cefc294050a9a86760e88d Gitweb: https://git.kernel.org/tip/0476a632cb3aa88c03cefc294050a9a86760e88d Author: Boqun Feng <boqun.f...@gmail.com> AuthorDate: Sat, 5 May 2018 19:28:17 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat, 5 Ma

[tip:locking/core] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

Commit-ID: 0476a632cb3aa88c03cefc294050a9a86760e88d Gitweb: https://git.kernel.org/tip/0476a632cb3aa88c03cefc294050a9a86760e88d Author: Boqun Feng AuthorDate: Sat, 5 May 2018 19:28:17 +0800 Committer: Ingo Molnar CommitDate: Sat, 5 May 2018 15:22:20 +0200 locking/atomics/powerpc: Move

Re: [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

On Sat, May 05, 2018 at 03:27:51PM +0200, Ingo Molnar wrote: > > * Boqun Feng <boqun.f...@gmail.com> wrote: > > > > May I suggest the patch below? No change in functionality, but it > > > documents the > > > lack of the cmpxchg_release() APIs and maps

Re: [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs

On Sat, May 05, 2018 at 03:27:51PM +0200, Ingo Molnar wrote: > > * Boqun Feng wrote: > > > > May I suggest the patch below? No change in functionality, but it > > > documents the > > > lack of the cmpxchg_release() APIs and maps them explicitly to the

Re: [RFC PATCH] locking/atomics/powerpc: Clarify why the cmpxchg_relaxed() family of APIs falls back to full cmpxchg()

On Sat, May 05, 2018 at 12:35:50PM +0200, Ingo Molnar wrote: > > * Boqun Feng <boqun.f...@gmail.com> wrote: > > > On Sat, May 05, 2018 at 11:38:29AM +0200, Ingo Molnar wrote: > > > > > > * Ingo Molnar <mi...@kernel.org> wrote: > > >

Re: [RFC PATCH] locking/atomics/powerpc: Clarify why the cmpxchg_relaxed() family of APIs falls back to full cmpxchg()

On Sat, May 05, 2018 at 12:35:50PM +0200, Ingo Molnar wrote: > > * Boqun Feng wrote: > > > On Sat, May 05, 2018 at 11:38:29AM +0200, Ingo Molnar wrote: > > > > > > * Ingo Molnar wrote: > > > > > > > * Peter Zijlstra wrote: > >

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

Hi Ingo, On Sat, May 05, 2018 at 12:00:55PM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > > So there's no loss in arch flexibility. > > > > BTW., PowerPC for example is already in such a situation, it does not > > define > > atomic_cmpxchg_release(), only the

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

Hi Ingo, On Sat, May 05, 2018 at 12:00:55PM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > > So there's no loss in arch flexibility. > > > > BTW., PowerPC for example is already in such a situation, it does not > > define > > atomic_cmpxchg_release(), only the other APIs: > > > >

Re: [PATCH] locking/atomics: Clean up the atomic.h maze of #defines

On Sat, May 05, 2018 at 11:38:29AM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > * Peter Zijlstra wrote: > > > > > > So we could do the following simplification on top of that: > > > > > > > > #ifndef atomic_fetch_dec_relaxed > > > > #

Re: [PATCH] locking/atomics: Clean up the atomic.h maze of #defines

On Sat, May 05, 2018 at 11:38:29AM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > * Peter Zijlstra wrote: > > > > > > So we could do the following simplification on top of that: > > > > > > > > #ifndef atomic_fetch_dec_relaxed > > > > # ifndef atomic_fetch_dec > > > > # define

Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning

(Copy more people) On Wed, Apr 11, 2018 at 09:50:51PM +0800, Boqun Feng wrote: > This patch add the documentation piece for the reasoning of deadlock > detection related to recursive read lock. The following sections are > added: > > * Explain what is a recursive read lock, an

Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning

(Copy more people) On Wed, Apr 11, 2018 at 09:50:51PM +0800, Boqun Feng wrote: > This patch add the documentation piece for the reasoning of deadlock > detection related to recursive read lock. The following sections are > added: > > * Explain what is a recursive read lock, an

Re: [PATCH] fasync: Fix deadlock between task-context and interrupt-context kill_fasync()

On Tue, Apr 17, 2018 at 07:01:10AM -0700, Matthew Wilcox wrote: > On Thu, Apr 05, 2018 at 02:58:06PM +0300, Kirill Tkhai wrote: > > I observed the following deadlock between them: > > > > [task 1] [task 2] [task 3] > > kill_fasync()

Re: [PATCH] fasync: Fix deadlock between task-context and interrupt-context kill_fasync()

On Tue, Apr 17, 2018 at 07:01:10AM -0700, Matthew Wilcox wrote: > On Thu, Apr 05, 2018 at 02:58:06PM +0300, Kirill Tkhai wrote: > > I observed the following deadlock between them: > > > > [task 1] [task 2] [task 3] > > kill_fasync()

Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning

On Sat, Apr 14, 2018 at 05:38:54PM -0700, Randy Dunlap wrote: > Hi, > Hello Randy, > Just a few typos etc. below... > Thanks! I fixed those typos according to your comments. > On 04/11/2018 06:50 AM, Boqun Feng wrote: > > Signed-off-by: Boqun Feng

Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning

On Sat, Apr 14, 2018 at 05:38:54PM -0700, Randy Dunlap wrote: > Hi, > Hello Randy, > Just a few typos etc. below... > Thanks! I fixed those typos according to your comments. > On 04/11/2018 06:50 AM, Boqun Feng wrote: > > Signed-off-by: Boqun Feng > > --- > &g

Re: [RFC tip/locking/lockdep v6 19/20] rcu: Equip sleepable RCU with lockdep dependency graph checks

On Thu, Apr 12, 2018 at 11:12:17AM +0200, Peter Zijlstra wrote: > On Thu, Apr 12, 2018 at 10:12:33AM +0800, Boqun Feng wrote: > > A trivial fix/hack would be adding local_irq_disable() and > > local_irq_enable() around srcu_lock_sync() like: > > > > static inline

Re: [RFC tip/locking/lockdep v6 19/20] rcu: Equip sleepable RCU with lockdep dependency graph checks

On Thu, Apr 12, 2018 at 11:12:17AM +0200, Peter Zijlstra wrote: > On Thu, Apr 12, 2018 at 10:12:33AM +0800, Boqun Feng wrote: > > A trivial fix/hack would be adding local_irq_disable() and > > local_irq_enable() around srcu_lock_sync() like: > > > > static inline

Re: [PATCH] memory-model: fix cheat sheet typo

On Wed, Apr 11, 2018 at 07:06:36PM +0200, Paolo Bonzini wrote: > On 11/04/2018 18:31, Peter Zijlstra wrote: > >>>Prior Operation Subsequent Operation > >>>--- - > >>>

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