Re: [PATCH] virtio-blk: free vblk-vqs in error path of virtblk_probe()

2020-06-30 Thread Jens Axboe
On 6/14/20 10:14 PM, Hou Tao wrote: > Else there will be memory leak if alloc_disk() fails. Applied, thanks. -- Jens Axboe ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH] virtio-blk: free vblk-vqs in error path of virtblk_probe()

2020-06-30 Thread Ming Lei
On Mon, Jun 15, 2020 at 12:14:59PM +0800, Hou Tao wrote: > Else there will be memory leak if alloc_disk() fails. > > Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per > virtio-blk device") > Signed-off-by: Hou Tao > --- > drivers/block/virtio_blk.c | 1 + > 1 file changed,

Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y

2020-06-30 Thread Peter Zijlstra
On Tue, Jun 30, 2020 at 09:47:30PM +0200, Marco Elver wrote: > I do wonder, though, if there is some way to make the compiler do > something better for us. Clearly, implementing real > memory_order_consume hasn't worked out until today. But maybe the > compiler could promote dependent loads to

Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y

2020-06-30 Thread Arnd Bergmann
On Tue, Jun 30, 2020 at 7:39 PM Will Deacon wrote: > +#define __READ_ONCE(x) \ > +({ \ > + int atomic = 1; \ > + union {

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

2020-06-30 Thread Arnd Bergmann
On Tue, Jun 30, 2020 at 7:37 PM 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 under

[PATCH 14/18] arm64: Reduce the number of header files pulled into vmlinux.lds.S

2020-06-30 Thread Will Deacon
Although vmlinux.lds.S smells like an assembly file and is compiled with __ASSEMBLY__ defined, it's actually just fed to the preprocessor to create our linker script. This means that any assembly macros defined by headers that it includes will result in a helpful link error: |

[PATCH 11/18] tools/memory-model: Remove smp_read_barrier_depends() from informal doc

2020-06-30 Thread Will Deacon
smp_read_barrier_depends() has gone the way of mmiowb() and so many esoteric memory barriers before it. Drop the two mentions of this deceased barrier from the LKMM informal explanation document. Acked-by: Alan Stern Acked-by: Paul E. McKenney Signed-off-by: Will Deacon ---

[PATCH 09/18] Documentation/barriers: Remove references to [smp_]read_barrier_depends()

2020-06-30 Thread Will Deacon
The [smp_]read_barrier_depends() barrier macros no longer exist as part of the Linux memory model, so remove all references to them from the Documentation/ directory. Although this is fairly mechanical on the whole, we drop the "CACHE COHERENCY" section entirely from 'memory-barriers.txt' as it

[PATCH 13/18] checkpatch: Remove checks relating to [smp_]read_barrier_depends()

2020-06-30 Thread Will Deacon
The [smp_]read_barrier_depends() macros no longer exist, so we don't need to deal with them in the checkpatch script. Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- scripts/checkpatch.pl | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git

[PATCH 17/18] arm64: alternatives: Remove READ_ONCE() usage during patch operation

2020-06-30 Thread Will Deacon
In preparation for patching the internals of READ_ONCE() itself, replace its usage on the alternatives patching patch with a volatile variable instead. Signed-off-by: Will Deacon --- arch/arm64/kernel/alternative.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[PATCH 15/18] arm64: alternatives: Split up alternative.h

2020-06-30 Thread Will Deacon
asm/alternative.h contains both the macros needed to use alternatives, as well the type definitions and function prototypes for applying them. Split the header in two, so that alternatives can be used from core header files such as linux/compiler.h without the risk of circular includes

[PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y

2020-06-30 Thread Will Deacon
When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic

[PATCH 16/18] arm64: cpufeatures: Add capability for LDAPR instruction

2020-06-30 Thread Will Deacon
Armv8.3 introduced the LDAPR instruction, which provides weaker memory ordering semantics than LDARi (RCpc vs RCsc). Generally, we provide an RCsc implementation when implementing the Linux memory model, but LDAPR can be used as a useful alternative to dependency ordering, particularly when the

[PATCH 06/18] vhost: Remove redundant use of read_barrier_depends() barrier

2020-06-30 Thread Will Deacon
Since commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), there is no need to use smp_read_barrier_depends() outside of the Alpha architecture code. Unfortunately, there is precisely _one_ user in the vhost code, and there isn't an obvious READ_ONCE()

[PATCH 12/18] include/linux: Remove smp_read_barrier_depends() from comments

2020-06-30 Thread Will Deacon
smp_read_barrier_depends() doesn't exist any more, so reword the two comments that mention it to refer to "dependency ordering" instead. Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- include/linux/percpu-refcount.h | 2 +- include/linux/ptr_ring.h| 2 +- 2 files changed, 2

[PATCH 10/18] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()

2020-06-30 Thread Will Deacon
From: SeongJae Park This commit translates commit ("Documentation/barriers: Remove references to [smp_]read_barrier_depends()") into Korean. Signed-off-by: SeongJae Park Reviewed-by: Yunjae Lee Signed-off-by: Will Deacon --- .../translations/ko_KR/memory-barriers.txt| 146

[PATCH 07/18] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb()

2020-06-30 Thread Will Deacon
In preparation for removing smp_read_barrier_depends() altogether, move the Alpha code over to using smp_rmb() and smp_mb() directly. Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- arch/alpha/include/asm/atomic.h | 16 arch/alpha/include/asm/pgtable.h | 10

[PATCH 08/18] locking/barriers: Remove definitions for [smp_]read_barrier_depends()

2020-06-30 Thread Will Deacon
There are no remaining users of [smp_]read_barrier_depends(), so remove it from the generic implementation of 'barrier.h'. Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- include/asm-generic/barrier.h | 17 - 1 file changed, 17 deletions(-) diff --git

[PATCH 05/18] asm/rwonce: Remove smp_read_barrier_depends() invocation

2020-06-30 Thread Will Deacon
Alpha overrides __READ_ONCE() directly, so there's no need to use smp_read_barrier_depends() in the core code. This also means that __READ_ONCE() can be relied upon to provide dependency ordering. Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- include/asm-generic/rwonce.h | 19

[PATCH 00/18] Allow architectures to override __READ_ONCE()

2020-06-30 Thread Will Deacon
Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-w...@kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during

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

2020-06-30 Thread Will Deacon
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 under 'asm-generic'. Acked-by: Paul E. McKenney Signed-off-by: Will

[PATCH 04/18] alpha: Override READ_ONCE() with barriered implementation

2020-06-30 Thread Will Deacon
Rather then relying on the core code to use smp_read_barrier_depends() as part of the READ_ONCE() definition, instead override __READ_ONCE() in the Alpha code so that it is treated the same way as smp_load_acquire(). Acked-by: Paul E. McKenney Signed-off-by: Will Deacon ---

[PATCH 01/18] tools: bpf: Use local copy of headers including uapi/linux/filter.h

2020-06-30 Thread Will Deacon
Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause

[PATCH 03/18] asm/rwonce: Allow __READ_ONCE to be overridden by the architecture

2020-06-30 Thread Will Deacon
The meat and potatoes of READ_ONCE() is defined by the __READ_ONCE() macro, which uses a volatile casts in an attempt to avoid tearing of byte, halfword, word and double-word accesses. Allow this to be overridden by the architecture code in the case that things like memory barriers are also

[PATCH v1 1/6] mm/page_alloc: tweak comments in has_unmovable_pages()

2020-06-30 Thread David Hildenbrand
Let's move the split comment regarding bootmem allocations and memory holes, especially in the context of ZONE_MOVABLE, to the PageReserved() check. Cc: Andrew Morton Cc: Michal Hocko Cc: Michael S. Tsirkin Signed-off-by: David Hildenbrand --- mm/page_alloc.c | 22 ++ 1

[PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()

2020-06-30 Thread David Hildenbrand
Right now, if we have two isolations racing, we might trigger the WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just return directly. In the future, we might want to report -EAGAIN to the caller instead, as this could indicate a temporary isolation failure only. Cc: Andrew

[PATCH v1 5/6] mm/page_alloc: restrict ZONE_MOVABLE optimization in has_unmovable_pages() to memory offlining

2020-06-30 Thread David Hildenbrand
We can already have pages that can be offlined but not allocated in ZONE_MOVABLE - PageHWPoison pages. While these pages can be skipped when offlining ("moving them to /dev/null"), we cannot move them when allocating. virtio-mem managed memory is similar. The logical memory holes corresponding to

[PATCH v1 3/6] mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate()

2020-06-30 Thread David Hildenbrand
Inside has_unmovable_pages(), we have a comment describing how unmovable data could end up in ZONE_MOVABLE - via "movable_core". Also, besides checking if the first page in the pageblock is reserved, we don't perform any further checks in case of ZONE_MOVABLE. In case of memory offlining, we set

[PATCH v1 0/6] mm / virtio-mem: support ZONE_MOVABLE

2020-06-30 Thread David Hildenbrand
Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising

[PATCH v1 4/6] mm/page_isolation: cleanup set_migratetype_isolate()

2020-06-30 Thread David Hildenbrand
Let's clean it up a bit, simplifying error handling and getting rid of the label. Cc: Andrew Morton Cc: Michal Hocko Cc: Michael S. Tsirkin Signed-off-by: David Hildenbrand --- mm/page_isolation.c | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git

[PATCH v1 6/6] virtio-mem: don't special-case ZONE_MOVABLE

2020-06-30 Thread David Hildenbrand
Let's allow to online partially plugged memory blocks to ZONE_MOVABLE and also consider memory blocks that were onlined to ZONE_MOVABLE when unplugging memory. While unplugged memory blocks are, in general, unmovable, they can be skipped when offlining memory. virtio-mem only unplugs fairly big

Re: [RFC 0/3] virtio: NUMA-aware memory allocation

2020-06-30 Thread Stefan Hajnoczi
On Mon, Jun 29, 2020 at 11:28:41AM -0400, Michael S. Tsirkin wrote: > On Mon, Jun 29, 2020 at 10:26:46AM +0100, Stefan Hajnoczi wrote: > > On Sun, Jun 28, 2020 at 02:34:37PM +0800, Jason Wang wrote: > > > > > > On 2020/6/25 下午9:57, Stefan Hajnoczi wrote: > > > > These patches are not ready to be

Re: [PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature

2020-06-30 Thread Cornelia Huck
On Mon, 29 Jun 2020 17:18:09 -0400 "Michael S. Tsirkin" wrote: > On Mon, Jun 29, 2020 at 06:48:28PM +0200, Pierre Morel wrote: > > > > > > On 2020-06-29 18:09, Michael S. Tsirkin wrote: > > > On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote: > > > > An architecture protecting