>Btw, what is the current state of converting intel-iommu to the dma-iommu
These changes expose a bug in the i915 intel driver which hasn't been
fixed yet. I don't think anyone is actively working on it but I plan
on merging as many patches as I can so it's easier to do the
intel-iommu -> dma-iomm
Sorry for the late reply -- a couple of conferences kept me busy.
On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> > Would you be in favor of a more flexible check along the lines of the
> > one proposed in the patch that starte
On Fri, Jul 10, 2020 at 10:06:12AM -0700, Nick Desaulniers wrote:
> On Fri, Jul 10, 2020 at 9:52 AM Will Deacon wrote:
> > diff --git a/include/linux/nospec.h b/include/linux/nospec.h
> > index 0c5ef54fd416..c1e79f72cd89 100644
> > --- a/include/linux/nospec.h
> > +++ b/include/linux/nospec.h
> >
On Fri, Jul 10, 2020 at 9:52 AM Will Deacon wrote:
>
> Now that 'smp_read_barrier_depends()' has gone the way of the Norwegian
> Blue, drop the inclusion of in 'asm-generic/rwonce.h'.
>
> This requires fixups to some architecture vdso headers which were
> previously relying on 'asm/barrier.h' com
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 com
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 generates the required mb() and then
implement smp_load_acquire() using the new macro to avoid redundant
back-to-back barriers fr
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
Signed-off
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 a/arch/a
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
---
.../Documentation/e
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
READ
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 i
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 a/scripts/checkpatch.pl
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 a/include/asm-ge
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 +--
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:
| aarch64-linux-gnu-ld
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 do
Hi all,
This is version three of the patches I previously posted here:
v1: https://lore.kernel.org/lkml/20191108170120.22331-1-w...@kernel.org/
v2: https://lore.kernel.org/r/20200630173734.14057-1-w...@kernel.org
Changes since v2 include:
* Actually add the barrier in READ_ONCE() for Alph
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 +
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 compiler.
Now that 'smp_read_barrier_depends()' has gone the way of the Norwegian
Blue, drop the inclusion of in 'asm-generic/rwonce.h'.
This requires fixups to some architecture vdso headers which were
previously relying on 'asm/barrier.h' coming in via 'linux/compiler.h'.
Signed-off-by: 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 --
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 require
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()
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
On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin wrote:
>
> Page reporting features were never supported by legacy hypervisors.
> Supporting them poses a problem: should we use native endian-ness (like
> current code assumes)? Or little endian-ness like the virtio spec says?
> Rather than try to
Btw, what is the current state of converting intel-iommu to the dma-iommu
code?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free
on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock'
pointer, but we forgot to annotate it.
This patch adds the annotation to fix the following sparse errors:
net/vmw_vsock/virtio_transport.c:73:17: error: in
On 10.07.20 13:31, Michael S. Tsirkin wrote:
> Page reporting features were never supported by legacy hypervisors.
> Supporting them poses a problem: should we use native endian-ness (like
> current code assumes)? Or little endian-ness like the virtio spec says?
> Rather than try to figure out, and
Page reporting features were never supported by legacy hypervisors.
Supporting them poses a problem: should we use native endian-ness (like
current code assumes)? Or little endian-ness like the virtio spec says?
Rather than try to figure out, and since results of
incorrect endian-ness are dire, let
On 10.07.20 12:48, Michael S. Tsirkin wrote:
> balloon uses virtio32_to_cpu instead of cpu_to_virtio32
> to convert a native endian number to virtio.
> No practical difference but makes sparse warn.
> Fix it up.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/virtio/virtio_balloon.c | 2 +-
balloon uses virtio32_to_cpu instead of cpu_to_virtio32
to convert a native endian number to virtio.
No practical difference but makes sparse warn.
Fix it up.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
virtio_store_mb was built with split ring in mind so it accepts
__virtio16 arguments. Packed ring uses __le16 values, so sparse
complains. It's just a store with some barriers so let's convert it to
a macro, we don't loose too much type safety by doing that.
Signed-off-by: Michael S. Tsirkin
---
vhost/scsi doesn't handle type conversion correctly
for request type when using virtio 1.0 and up for BE,
or cross-endian platforms.
Fix it up using vhost_32_to_cpu.
Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 d
On Fri, Jul 10, 2020 at 06:24:51AM -0400, Michael S. Tsirkin wrote:
> RCU trickery:
>
> net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock [noderef]
> __rcu *
>
RCU trickery:
net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison
expression (different address spaces):
net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock [noderef] __rcu *
net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock *
net/vmw_vsock/virt
On 10/07/20 09:40, Markus Elfring wrote:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/virtio_scsi.c?id=42f82040ee66db13525dc6f14b8559890b2f4c1c#n980
>>>
>>> if (!virtscsi_cmd_cache) {
>>> pr_err("kmem_cache_create() for virtscsi_cmd_cache
On 10/07/20 08:32, Markus Elfring wrote:
+ mempool_destroy(virtscsi_cmd_pool);
+ virtscsi_cmd_pool = NULL;
+ kmem_cache_destroy(virtscsi_cmd_cache);
+ virtscsi_cmd_cache = NULL;
return ret;
}
>>>
>>> How do you think about to add a jump target so that the execu
37 matches
Mail list logo
