* Re: [Xen-devel] [PATCH] xen/arm: fix build after 2e35cdf
From: Volodymyr Babchuk @ 2019-06-20 11:05 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org, Julien Grall, Volodymyr Babchuk,
andrew.cooper3@citrix.com
In-Reply-To: <alpine.DEB.2.21.1906191446280.2072@sstabellini-ThinkPad-T480s>
Hi Stefano, Julien,
Stefano Stabellini writes:
> On Wed, 19 Jun 2019, Julien Grall wrote:
>> Hi Stefano,
>>
>> Title: You should at least mention this is for op-tee.
>>
>> Also, mostly likely the sha1 is too small and likely to match multiple commit
>> in the future. So you want to specify the title of the commit.
>>
>> On 6/19/19 10:24 PM, Stefano Stabellini wrote:
>> > Optee breaks the build with:
>> >
>> > optee.c: In function ‘translate_noncontig.isra.4’:
>> > optee.c:743:38: error: ‘xen_data’ may be used uninitialized in this function
>> > [-Werror=maybe-uninitialized]
>> > xen_data->next_page_data = page_to_maddr(xen_pgs + 1);
>> > ^
>> > optee.c:732:71: error: ‘guest_data’ may be used uninitialized in this
>> > function [-Werror=maybe-uninitialized]
>> > page =
>> > get_domain_ram_page(gaddr_to_gfn(guest_data->pages_list[idx]));
>> > ^
>> > optee.c:750:21: error: ‘guest_pg’ may be used uninitialized in this function
>> > [-Werror=maybe-uninitialized]
>> > put_page(guest_pg);
>> > ^
>> > cc1: all warnings being treated as errors
>> >
>> > Fix it by initializing xen_data, guest_data, guest_pg to NULL. Also set
>> > xen_pgs to NULL for consistency.
>>
>> Without more explanation I think this is an unwise choice. If GCC thinks it is
>> going to be used unitialized, then mostly likely you silent an error that
>> could end up to dereference NULL.
There is no way to use this variables without initialization. They are
always initialized on the first iteration of the loop, when idx equals
to 0. Newer version of GCC can infer this, but look like this causes
problem for older versions.
>> Also, setting xen_pgs for consistency will only defeat the compiler. Leading
>> to dereferencing NULL and crash Xen...
>>
>> For xen_pgs, this should definitely not be NULL. For the two others, you need
>> to explain why this is fine (if this is just because the compiler can't find
>> the reason, then you should add a comment in the code to explain it).
>
> I was only trying to unblock the build. I'll withdraw the patch and let
> Volodmir fix it properly.
Actually, your patch is fine, taking into account Julien's comment about
xen_pgs and justification in the comments.
So, you can send fixed version or I can do this, if you don't want to.
>
> Volodmir, FYI I reproduced the issue using Ubuntu Trusty gcc
> 4.8.4-2ubuntu1~14.04.3.
Oh, I see. This is the quite old version of GCC. I'm using
aarch64-poky-linux-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
which is also old, but at least it tracks variables initialization
better.
--
Best regards,Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t 5/5] docs: Embed subtest descriptions in the documentation
From: Ser, Simon @ 2019-06-20 11:05 UTC (permalink / raw)
To: Hiler, Arkadiusz, igt-dev@lists.freedesktop.org, daniel@ffwll.ch
In-Reply-To: <20190620105225.72w3opn6qccyqn2e@ahiler-desk1.fi.intel.com>
On Thu, 2019-06-20 at 13:52 +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 20, 2019 at 11:20:18AM +0300, Petri Latvala wrote:
> > On Mon, Jun 17, 2019 at 01:54:43PM +0300, Arkadiusz Hiler wrote:
> > > This rewrites generate_description_xml in Python, so that we generate
> > > properly escaped XML. The switch also makes the code more manageable.
> > >
> > > Changes in the generated docbook:
> > >
> > > 1. subtests are not simply listed anymore, they are now another (sub)section
> > >
> > > 2. subtests are now linkable,
> > > e.g. docs/igt-kms-tests.html#kms_hdmi_inject@inject-4k
> > >
> > > 3. subtest's section now includes output of --describe
> > >
> > > Python is required already by gtk-doc and we are not using anything
> > > other than the standard library.
> >
> > Python yes, but what about python3? My Debian installation is ancient
> > even on Debian standards and gtk-doc-tools depends on python2. I'm too
> > lazy to check if the version used by gitlab-CI depends on python3, so
> > asking instead: Do you have a fork in gitlab for this? :P
>
> It works on Fedora:
>
> % head -n 1 $(which gtkdoc-mkhtml)
> #!/usr/bin/python3
I believe `#!/usr/bin/env python3` is more correct.
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml#L174
>
>
> But for explicitness I can squash in:
>
> diff --git a/docs/reference/igt-gpu-tools/meson.build b/docs/reference/igt-gpu-tools/meson.build
> index e2bdc495..b3a4c0bd 100644
> --- a/docs/reference/igt-gpu-tools/meson.build
> +++ b/docs/reference/igt-gpu-tools/meson.build
> @@ -45,6 +45,7 @@ test_groups = [
> 'vgem',
> ]
>
> +find_program('python3') # required by doc generators
> gen_description = find_program('generate_description_xml.py')
> gen_programs = find_program('generate_programs_xml.sh')
>
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 0/4] target/mips: Misc fixes and maintenance for 4.1
From: Aleksandar Rikalo @ 2019-06-20 10:24 UTC (permalink / raw)
To: Aleksandar Markovic, qemu-devel@nongnu.org; +Cc: Aleksandar Markovic
In-Reply-To: <1561024929-26004-1-git-send-email-aleksandar.markovic@rt-rk.com>
> From: Aleksandar Markovic <aleksandar.markovic@rt-rk.com>
> Sent: Thursday, June 20, 2019 12:02 PM
> To: qemu-devel@nongnu.org
> Cc: Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH v3 0/4] target/mips: Misc fixes and maintenance for 4.1
>
> From: Aleksandar Markovic <amarkovic@wavecomp.com>
>
> This series contains miscelaneous fixes, improvements, and
> maintainance items intended to be integrated into QEMU 4.1.
> I will gradually add patches by the end of June 2019.
>
> v2->v3:
>
> - amendeded two patches on cleaning checkpatch warnings
>
> v1->v2:
>
> - added two patches on cleaning checkpatch warnings
>
> Aleksandar Markovic (4):
> MAINTAINERS: Update file items for MIPS Malta board
> MAINTAINERS: Consolidate MIPS disassembler-related items
> target/mips: Fix some space checkpatch errors in translate.c
> target/mips: Fix if-else-switch-case arms checkpatch errors in
> translate.c
>
> MAINTAINERS | 6 +-
> target/mips/translate.c | 445 +++++++++++++++++++++++++++---------------------
> 2 files changed, 257 insertions(+), 194 deletions(-)
>
> --
> 2.7.4
For the whole series.
Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 05/17] tests/vm: send proxy environment variables over ssh
From: Philippe Mathieu-Daudé @ 2019-06-20 10:38 UTC (permalink / raw)
To: Alex Bennée, qemu-devel; +Cc: Fam Zheng, Thomas Huth, Gerd Hoffmann
In-Reply-To: <20190619194021.8240-6-alex.bennee@linaro.org>
On 6/19/19 9:40 PM, Alex Bennée wrote:
> From: Gerd Hoffmann <kraxel@redhat.com>
>
> Packages are fetched via proxy that way, if configured on the host.
> That might be required to pass firewalls, and it allows to route
> package downloads through a caching proxy server.
>
> Needs AcceptEnv setup in sshd_config on the guest side to work.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Tested-by: Thomas Huth <thuth@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Message-Id: <20190617043858.8290-2-kraxel@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> tests/vm/basevm.py | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> index 4847549592..5e30bac661 100755
> --- a/tests/vm/basevm.py
> +++ b/tests/vm/basevm.py
> @@ -38,6 +38,13 @@ class BaseVM(object):
> GUEST_PASS = "qemupass"
> ROOT_PASS = "qemupass"
>
> + envvars = [
> + "https_proxy",
> + "http_proxy",
> + "ftp_proxy",
> + "no_proxy",
> + ]
> +
> # The script to run in the guest that builds QEMU
> BUILD_SCRIPT = ""
> # The guest name, to be overridden by subclasses
> @@ -106,6 +113,8 @@ class BaseVM(object):
> "-o", "UserKnownHostsFile=" + os.devnull,
> "-o", "ConnectTimeout=1",
> "-p", self.ssh_port, "-i", self._ssh_key_file]
> + for var in self.envvars:
> + ssh_cmd += ['-o', "SendEnv=%s" % var ]
> if interactive:
> ssh_cmd += ['-t']
> assert not isinstance(cmd, str)
>
^ permalink raw reply
* Re: [PATCH 2/3] jbd2: introduce jbd2_inode dirty range scoping
From: Jan Kara @ 2019-06-20 11:04 UTC (permalink / raw)
To: Ross Zwisler
Cc: linux-kernel, Ross Zwisler, Theodore Ts'o, Alexander Viro,
Andreas Dilger, Jan Kara, linux-ext4, linux-fsdevel, linux-mm,
Fletcher Woodruff, Justin TerAvest
In-Reply-To: <20190619172156.105508-3-zwisler@google.com>
On Wed 19-06-19 11:21:55, Ross Zwisler wrote:
> Currently both journal_submit_inode_data_buffers() and
> journal_finish_inode_data_buffers() operate on the entire address space
> of each of the inodes associated with a given journal entry. The
> consequence of this is that if we have an inode where we are constantly
> appending dirty pages we can end up waiting for an indefinite amount of
> time in journal_finish_inode_data_buffers() while we wait for all the
> pages under writeback to be written out.
>
> The easiest way to cause this type of workload is do just dd from
> /dev/zero to a file until it fills the entire filesystem. This can
> cause journal_finish_inode_data_buffers() to wait for the duration of
> the entire dd operation.
>
> We can improve this situation by scoping each of the inode dirty ranges
> associated with a given transaction. We do this via the jbd2_inode
> structure so that the scoping is contained within jbd2 and so that it
> follows the lifetime and locking rules for that structure.
>
> This allows us to limit the writeback & wait in
> journal_submit_inode_data_buffers() and
> journal_finish_inode_data_buffers() respectively to the dirty range for
> a given struct jdb2_inode, keeping us from waiting forever if the inode
> in question is still being appended to.
>
> Signed-off-by: Ross Zwisler <zwisler@google.com>
The patch looks good to me. I was thinking whether we should not have
separate ranges for current and the next transaction but I guess it is not
worth it at least for now. So just one nit below. With that applied feel free
to add:
Reviewed-by: Jan Kara <jack@suse.cz>
> @@ -257,15 +262,24 @@ static int journal_finish_inode_data_buffers(journal_t *journal,
> /* For locking, see the comment in journal_submit_data_buffers() */
> spin_lock(&journal->j_list_lock);
> list_for_each_entry(jinode, &commit_transaction->t_inode_list, i_list) {
> + loff_t dirty_start = jinode->i_dirty_start;
> + loff_t dirty_end = jinode->i_dirty_end;
> +
> if (!(jinode->i_flags & JI_WAIT_DATA))
> continue;
> jinode->i_flags |= JI_COMMIT_RUNNING;
> spin_unlock(&journal->j_list_lock);
> - err = filemap_fdatawait_keep_errors(
> - jinode->i_vfs_inode->i_mapping);
> + err = filemap_fdatawait_range_keep_errors(
> + jinode->i_vfs_inode->i_mapping, dirty_start,
> + dirty_end);
> if (!ret)
> ret = err;
> spin_lock(&journal->j_list_lock);
> +
> + if (!jinode->i_next_transaction) {
> + jinode->i_dirty_start = 0;
> + jinode->i_dirty_end = 0;
> + }
This would be more logical in the next loop that moves jinode into the next
transaction.
> jinode->i_flags &= ~JI_COMMIT_RUNNING;
> smp_mb();
> wake_up_bit(&jinode->i_flags, __JI_COMMIT_RUNNING);
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v5] arm64: kernel: implement fast refcount checking
From: Jan Glauber @ 2019-06-20 11:03 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Kees Cook, Catalin Marinas, Will Deacon,
Jayachandran Chandrasekharan Nair, Hanjun Guo, Andrew Murray,
Linus Torvalds, linux-arm-kernel
In-Reply-To: <CAKv+Gu-eWP7BNSgYzQgrKGdsEHj1pvv9wAhW9jrorj775DJ_-g@mail.gmail.com>
On Wed, Jun 19, 2019 at 12:56:41PM +0200, Ard Biesheuvel wrote:
> (add Andrew, who has been looking at the atomics code as well)
>
> On Wed, 19 Jun 2019 at 12:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> > This adds support to arm64 for fast refcount checking, as contributed
> > by Kees for x86 based on the implementation by grsecurity/PaX.
> >
> > The general approach is identical: the existing atomic_t helpers are
> > cloned for refcount_t, with the arithmetic instruction modified to set
> > the PSTATE flags, and one or two branch instructions added that jump to
> > an out of line handler if overflow, decrement to zero or increment from
> > zero are detected.
> >
> > One complication that we have to deal with on arm64 is the fact that
> > it has two atomics implementations: the original LL/SC implementation
> > using load/store exclusive loops, and the newer LSE one that does mostly
> > the same in a single instruction. So we need to clone some parts of
> > both for the refcount handlers, but we also need to deal with the way
> > LSE builds fall back to LL/SC at runtime if the hardware does not
> > support it.
> >
> > As is the case with the x86 version, the performance gain is substantial
> > (ThunderX2 @ 2.2 GHz, using LSE), even though the arm64 implementation
> > incorporates an add-from-zero check as well:
> >
> > perf stat -B -- echo ATOMIC_TIMING >/sys/kernel/debug/provoke-crash/DIRECT
> >
> > 116252672661 cycles # 2.207 GHz
> >
> > 52.689793525 seconds time elapsed
> >
> > perf stat -B -- echo REFCOUNT_TIMING >/sys/kernel/debug/provoke-crash/DIRECT
> >
> > 127060259162 cycles # 2.207 GHz
> >
> > 57.243690077 seconds time elapsed
> >
> > For comparison, the numbers below were captured using CONFIG_REFCOUNT_FULL,
> > which uses the validation routines implemented in C using cmpxchg():
> >
> > perf stat -B -- echo REFCOUNT_TIMING >/sys/kernel/debug/provoke-crash/DIRECT
> >
> > Performance counter stats for 'cat /dev/fd/63':
> >
> > 191057942484 cycles # 2.207 GHz
> >
> > 86.568269904 seconds time elapsed
> >
> > As a bonus, this code has been found to perform significantly better on
> > systems with many CPUs, due to the fact that it no longer relies on the
> > load/compare-and-swap combo performed in a tight loop, which is what we
> > emit for cmpxchg() on arm64.
Great work! With that series refcount is no longer the top spot for the
open-close testcase on TX2 (with a distro-like config).
Minor unrelated nit - shouldn't the new refcount.h use the modern
SPDX-License-Identifier thing?
--Jan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v4] eal: rename state values in rte_lcore_state
From: David Marchand @ 2019-06-20 11:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
In-Reply-To: <20190619192215.25923-1-stephen@networkplumber.org>
On Wed, Jun 19, 2019 at 9:24 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> C language does not really treat enum's as first class symbols.
> The values in an enum live in a global namespace. That means if
> DPDK defines "RUNNING" it can't be used by another enum in an
> application using DPDK.
>
> To solve this add a prefix "RTE_LCORE_" to the enum values, and
> make them grammatically consistent.
>
> Also, simplify the inline thread_is_running() which is copied
> in softnic and ip_pipeline.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> v4 - rebase (after lcore changes),fix FreeBSD typo
>
>
Did an extra pass, you missed the windows eal and the api descriptions:
https://github.com/david-marchand/dpdk/commit/0084114455a82f90b783bdf1659a4af6f76c89f2
My only objection to this patch is that we are breaking a public API by
removing those enums.
We need to maintain those and send a deprecation notice for their future
removal.
--
David Marchand
^ permalink raw reply
* [PATCH net] tipc: add dst_cache support for udp media
From: Xin Long @ 2019-06-20 11:03 UTC (permalink / raw)
To: network dev; +Cc: davem, Jon Maloy, Ying Xue, tipc-discussion, Paolo Abeni
As other udp/ip tunnels do, tipc udp media should also have a
lockless dst_cache supported on its tx path.
Here we add dst_cache into udp_replicast to support dst cache
for both rmcast and rcast, and rmcast uses ub->rcast and each
rcast uses its own node in ub->rcast.list.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/tipc/udp_media.c | 72 ++++++++++++++++++++++++++++++++++------------------
1 file changed, 47 insertions(+), 25 deletions(-)
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 1405ccc..b8962df 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -76,6 +76,7 @@ struct udp_media_addr {
/* struct udp_replicast - container for UDP remote addresses */
struct udp_replicast {
struct udp_media_addr addr;
+ struct dst_cache dst_cache;
struct rcu_head rcu;
struct list_head list;
};
@@ -158,22 +159,27 @@ static int tipc_udp_addr2msg(char *msg, struct tipc_media_addr *a)
/* tipc_send_msg - enqueue a send request */
static int tipc_udp_xmit(struct net *net, struct sk_buff *skb,
struct udp_bearer *ub, struct udp_media_addr *src,
- struct udp_media_addr *dst)
+ struct udp_media_addr *dst, struct dst_cache *cache)
{
+ struct dst_entry *ndst = dst_cache_get(cache);
int ttl, err = 0;
- struct rtable *rt;
if (dst->proto == htons(ETH_P_IP)) {
- struct flowi4 fl = {
- .daddr = dst->ipv4.s_addr,
- .saddr = src->ipv4.s_addr,
- .flowi4_mark = skb->mark,
- .flowi4_proto = IPPROTO_UDP
- };
- rt = ip_route_output_key(net, &fl);
- if (IS_ERR(rt)) {
- err = PTR_ERR(rt);
- goto tx_error;
+ struct rtable *rt = (struct rtable *)ndst;
+
+ if (!rt) {
+ struct flowi4 fl = {
+ .daddr = dst->ipv4.s_addr,
+ .saddr = src->ipv4.s_addr,
+ .flowi4_mark = skb->mark,
+ .flowi4_proto = IPPROTO_UDP
+ };
+ rt = ip_route_output_key(net, &fl);
+ if (IS_ERR(rt)) {
+ err = PTR_ERR(rt);
+ goto tx_error;
+ }
+ dst_cache_set_ip4(cache, &rt->dst, fl.saddr);
}
ttl = ip4_dst_hoplimit(&rt->dst);
@@ -182,17 +188,19 @@ static int tipc_udp_xmit(struct net *net, struct sk_buff *skb,
dst->port, false, true);
#if IS_ENABLED(CONFIG_IPV6)
} else {
- struct dst_entry *ndst;
- struct flowi6 fl6 = {
- .flowi6_oif = ub->ifindex,
- .daddr = dst->ipv6,
- .saddr = src->ipv6,
- .flowi6_proto = IPPROTO_UDP
- };
- err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk, &ndst,
- &fl6);
- if (err)
- goto tx_error;
+ if (!ndst) {
+ struct flowi6 fl6 = {
+ .flowi6_oif = ub->ifindex,
+ .daddr = dst->ipv6,
+ .saddr = src->ipv6,
+ .flowi6_proto = IPPROTO_UDP
+ };
+ err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk,
+ &ndst, &fl6);
+ if (err)
+ goto tx_error;
+ dst_cache_set_ip6(cache, ndst, &fl6.saddr);
+ }
ttl = ip6_dst_hoplimit(ndst);
err = udp_tunnel6_xmit_skb(ndst, ub->ubsock->sk, skb, NULL,
&src->ipv6, &dst->ipv6, 0, ttl, 0,
@@ -230,7 +238,8 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
}
if (addr->broadcast != TIPC_REPLICAST_SUPPORT)
- return tipc_udp_xmit(net, skb, ub, src, dst);
+ return tipc_udp_xmit(net, skb, ub, src, dst,
+ &ub->rcast.dst_cache);
/* Replicast, send an skb to each configured IP address */
list_for_each_entry_rcu(rcast, &ub->rcast.list, list) {
@@ -242,7 +251,8 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
goto out;
}
- err = tipc_udp_xmit(net, _skb, ub, src, &rcast->addr);
+ err = tipc_udp_xmit(net, _skb, ub, src, &rcast->addr,
+ &rcast->dst_cache);
if (err)
goto out;
}
@@ -286,6 +296,11 @@ static int tipc_udp_rcast_add(struct tipc_bearer *b,
if (!rcast)
return -ENOMEM;
+ if (dst_cache_init(&rcast->dst_cache, GFP_ATOMIC)) {
+ kfree(rcast);
+ return -ENOMEM;
+ }
+
memcpy(&rcast->addr, addr, sizeof(struct udp_media_addr));
if (ntohs(addr->proto) == ETH_P_IP)
@@ -742,6 +757,10 @@ static int tipc_udp_enable(struct net *net, struct tipc_bearer *b,
tuncfg.encap_destroy = NULL;
setup_udp_tunnel_sock(net, ub->ubsock, &tuncfg);
+ err = dst_cache_init(&ub->rcast.dst_cache, GFP_ATOMIC);
+ if (err)
+ goto err;
+
/**
* The bcast media address port is used for all peers and the ip
* is used if it's a multicast address.
@@ -756,6 +775,7 @@ static int tipc_udp_enable(struct net *net, struct tipc_bearer *b,
return 0;
err:
+ dst_cache_destroy(&ub->rcast.dst_cache);
if (ub->ubsock)
udp_tunnel_sock_release(ub->ubsock);
kfree(ub);
@@ -769,10 +789,12 @@ static void cleanup_bearer(struct work_struct *work)
struct udp_replicast *rcast, *tmp;
list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {
+ dst_cache_destroy(&rcast->dst_cache);
list_del_rcu(&rcast->list);
kfree_rcu(rcast, rcu);
}
+ dst_cache_destroy(&ub->rcast.dst_cache);
if (ub->ubsock)
udp_tunnel_sock_release(ub->ubsock);
synchronize_net();
--
2.1.0
^ permalink raw reply related
* [SPDK] RDMA in-line data transfer for host READ operations.
From: Kumar, Amit1 @ 2019-06-20 11:03 UTC (permalink / raw)
To: spdk
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi All,
I was looking at the NVMe Data-in and Data-out flow for NVMeOF RDMA transport, looks like SPDK is capable of handling in-capsule data (for Write operations from the host) by pre-posting in-capsule data buffer SGL to RDMA recv buffers. But, looks like SPDK doesn't use in-line data buffers while sending response to the NVMe read commands from the host and eventually using RDMA write to send the data, can someone please confirm whether my observation is correct or not?
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH V10 15/15] arm64: Add Tegra194 PCIe driver to defconfig
From: Thierry Reding @ 2019-06-20 11:03 UTC (permalink / raw)
To: Vidya Sagar
Cc: lorenzo.pieralisi, bhelgaas, robh+dt, mark.rutland, jonathanh,
kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <20190612095339.20118-16-vidyas@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
On Wed, Jun 12, 2019 at 03:23:39PM +0530, Vidya Sagar wrote:
> Add PCIe host controller driver for DesignWare core based
> PCIe controller IP present in Tegra194.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> Changes since [v9]:
> * None
>
> Changes since [v8]:
> * None
>
> Changes since [v7]:
> * None
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * None
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * None
>
> Changes since [v2]:
> * None
>
> Changes since [v1]:
> * Changed CONFIG_PCIE_TEGRA194 from 'y' to 'm'
>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
Applied to for-5.3/arm64/defconfig, thanks.
Thierry
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index bb0705e1f52e..6462a4dbac87 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -192,6 +192,7 @@ CONFIG_PCIE_QCOM=y
> CONFIG_PCIE_ARMADA_8K=y
> CONFIG_PCIE_KIRIN=y
> CONFIG_PCIE_HISI_STB=y
> +CONFIG_PCIE_TEGRA194=m
> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> --
> 2.17.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V10 15/15] arm64: Add Tegra194 PCIe driver to defconfig
From: Thierry Reding @ 2019-06-20 11:03 UTC (permalink / raw)
To: Vidya Sagar
Cc: mark.rutland, devicetree, lorenzo.pieralisi, mperttunen,
mmaddireddy, linux-pci, catalin.marinas, will.deacon,
linux-kernel, kthota, kishon, linux-tegra, robh+dt,
gustavo.pimentel, jingoohan1, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190612095339.20118-16-vidyas@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 1194 bytes --]
On Wed, Jun 12, 2019 at 03:23:39PM +0530, Vidya Sagar wrote:
> Add PCIe host controller driver for DesignWare core based
> PCIe controller IP present in Tegra194.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> Changes since [v9]:
> * None
>
> Changes since [v8]:
> * None
>
> Changes since [v7]:
> * None
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * None
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * None
>
> Changes since [v2]:
> * None
>
> Changes since [v1]:
> * Changed CONFIG_PCIE_TEGRA194 from 'y' to 'm'
>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
Applied to for-5.3/arm64/defconfig, thanks.
Thierry
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index bb0705e1f52e..6462a4dbac87 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -192,6 +192,7 @@ CONFIG_PCIE_QCOM=y
> CONFIG_PCIE_ARMADA_8K=y
> CONFIG_PCIE_KIRIN=y
> CONFIG_PCIE_HISI_STB=y
> +CONFIG_PCIE_TEGRA194=m
> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> --
> 2.17.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC 0/5] x86/KVM/svm: get rid of hardcoded instructions lengths
From: Vitaly Kuznetsov @ 2019-06-20 11:02 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Jim Mattson
Jim rightfully complains that hardcoding instuctions lengths is not always
correct: additional (redundant) prefixes can be used. Luckily, the ugliness
is mostly harmless: modern AMD CPUs support NRIP_SAVE feature but I'd like
to clean things up and sacrifice speed in favor of correctness.
Early RFC. Unfortunately, I got distracted by some other problems so
sending it out half-baked.
TODO:
- Get rid of hardcoded '+ 3' in vmrun_interception().
- Test.
P.S. If you'd like to test the series you'll have to have a CPU without
NRIP_SAVE feature or forcefully disable it, something like:
index 8d4e50428b68..93c7eaad7915 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -922,6 +922,9 @@ static void init_amd(struct cpuinfo_x86 *c)
/* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
if (!cpu_has(c, X86_FEATURE_XENPV))
set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+
+ /* No nrips */
+ clear_cpu_cap(c, X86_FEATURE_NRIPS);
}
#ifdef CONFIG_X86_32
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5beca1030c9a..5b2ea34bc9f2 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -773,11 +773,11 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
- if (svm->vmcb->control.next_rip != 0) {
+/* if (svm->vmcb->control.next_rip != 0) {
WARN_ON_ONCE(!static_cpu_has(X86_FEATURE_NRIPS));
svm->next_rip = svm->vmcb->control.next_rip;
}
-
+*/
if (!svm->next_rip) {
if (kvm_emulate_instruction(vcpu, EMULTYPE_SKIP) !=
EMULATE_DONE)
Vitaly Kuznetsov (5):
x86: KVM: svm: don't pretend to advance RIP in case
wrmsr_interception() results in #GP
x86: KVM: svm: avoid flooding logs when skip_emulated_instruction()
fails
x86: KVM: svm: clear interrupt shadow on all paths in
skip_emulated_instruction()
x86: KVM: add xsetbv to the emulator
x86: KVM: svm: remove hardcoded instruction length from intercepts
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/kvm/emulate.c | 9 ++++++++-
arch/x86/kvm/svm.c | 19 ++++++-------------
3 files changed, 15 insertions(+), 14 deletions(-)
--
2.20.1
^ permalink raw reply related
* Re: How to write "modern" pinctrl DT node
From: Marc Gonzalez @ 2019-06-20 11:02 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: Linus Walleij, MSM, gpio, Jeffrey Hugo
In-Reply-To: <20190611180516.GO4814@minitux>
On 11/06/2019 20:05, Bjorn Andersson wrote:
> Also, what's up with tsif0 vs tsif1?
Some people count from 0; other people count from 1.
The HW programming guide mentions TSIF_0 and TSIF_1.
The pinctrl driver defines tsif1 and tsif2.
I propose we use 0 and 1 consistently everywhere.
> PS. I would suggest that you send a patch to the MSM8998 pinctrl driver
> (and binding) where you squash tsifN_* to tsifN. It would break
> backwards compatibility, but I think we can take that risk now before
> someone starts to use it... And after that you can go with your proposed
> squashed node.
Here's what I have right now:
$ git ls --stat 85c02fb4dfd1..HEAD
5ed38c44a92a (HEAD -> tsif-fixup) Fixup qcom,msm8998-pinctrl.txt example
Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
823402af81a6 Fixup qcom,msm8998-pinctrl.txt binding
Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
afb686b8b3e7 Squash all 5 tsif1 pins together
drivers/pinctrl/qcom/pinctrl-msm8998.c | 38 +++++++++-----------------------------
1 file changed, 9 insertions(+), 29 deletions(-)
8e4d31c8d455 Squash all 5 tsif0 pins together
drivers/pinctrl/qcom/pinctrl-msm8998.c | 38 +++++++++-----------------------------
1 file changed, 9 insertions(+), 29 deletions(-)
ee850fa510a6 sed -i 's/tsif2/tsif1/g' drivers/pinctrl/qcom/pinctrl-msm8998.c
drivers/pinctrl/qcom/pinctrl-msm8998.c | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
c7ffe4075623 sed -i 's/tsif1/tsif0/g' drivers/pinctrl/qcom/pinctrl-msm8998.c
drivers/pinctrl/qcom/pinctrl-msm8998.c | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
I'm wondering if the series needs to be split up (as it is) or squashed
into a single patch (might be harder to review for mistakes).
What do you think?
Regards.
^ permalink raw reply
* [PATCH RFC 2/5] x86: KVM: svm: avoid flooding logs when skip_emulated_instruction() fails
From: Vitaly Kuznetsov @ 2019-06-20 11:02 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Jim Mattson
In-Reply-To: <20190620110240.25799-1-vkuznets@redhat.com>
When we're unable to skip instruction with kvm_emulate_instruction() we
will not advance RIP and most likely the guest will get stuck as
consequitive attempts to execute the same instruction will likely result
in the same behavior.
As we're not supposed to see these messages under normal conditions, switch
to pr_err_once().
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
arch/x86/kvm/svm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 982c6b9bfc90..68f1f0218c95 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -781,7 +781,8 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
if (!svm->next_rip) {
if (kvm_emulate_instruction(vcpu, EMULTYPE_SKIP) !=
EMULATE_DONE)
- printk(KERN_DEBUG "%s: NOP\n", __func__);
+ pr_err_once("KVM: %s: unable to skip instruction\n",
+ __func__);
return;
}
if (svm->next_rip - kvm_rip_read(vcpu) > MAX_INST_SIZE)
--
2.20.1
^ permalink raw reply related
* [PATCH RFC 3/5] x86: KVM: svm: clear interrupt shadow on all paths in skip_emulated_instruction()
From: Vitaly Kuznetsov @ 2019-06-20 11:02 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Jim Mattson
In-Reply-To: <20190620110240.25799-1-vkuznets@redhat.com>
Regardless of the way how we skip instruction, interrupt shadow needs to be
cleared.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 68f1f0218c95..f980fc43372d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -783,13 +783,15 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
EMULATE_DONE)
pr_err_once("KVM: %s: unable to skip instruction\n",
__func__);
- return;
+ goto clear_int_shadow;
}
if (svm->next_rip - kvm_rip_read(vcpu) > MAX_INST_SIZE)
printk(KERN_ERR "%s: ip 0x%lx next 0x%llx\n",
__func__, kvm_rip_read(vcpu), svm->next_rip);
kvm_rip_write(vcpu, svm->next_rip);
+
+clear_int_shadow:
svm_set_interrupt_shadow(vcpu, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH RFC 4/5] x86: KVM: add xsetbv to the emulator
From: Vitaly Kuznetsov @ 2019-06-20 11:02 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Jim Mattson
In-Reply-To: <20190620110240.25799-1-vkuznets@redhat.com>
To avoid hardcoding xsetbv length to '3' we need to support decoding it in
the emulator.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/kvm/emulate.c | 9 ++++++++-
arch/x86/kvm/svm.c | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h b/arch/x86/include/asm/kvm_emulate.h
index feab24cac610..478f76b0122d 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -429,6 +429,7 @@ enum x86_intercept {
x86_intercept_ins,
x86_intercept_out,
x86_intercept_outs,
+ x86_intercept_xsetbv,
nr_x86_intercepts
};
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d0d5dd44b4f4..ff25d94df684 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4393,6 +4393,12 @@ static const struct opcode group7_rm1[] = {
N, N, N, N, N, N,
};
+static const struct opcode group7_rm2[] = {
+ N,
+ DI(SrcNone | Priv, xsetbv),
+ N, N, N, N, N, N,
+};
+
static const struct opcode group7_rm3[] = {
DIP(SrcNone | Prot | Priv, vmrun, check_svme_pa),
II(SrcNone | Prot | EmulateOnUD, em_hypercall, vmmcall),
@@ -4482,7 +4488,8 @@ static const struct group_dual group7 = { {
}, {
EXT(0, group7_rm0),
EXT(0, group7_rm1),
- N, EXT(0, group7_rm3),
+ EXT(0, group7_rm2),
+ EXT(0, group7_rm3),
II(SrcNone | DstMem | Mov, em_smsw, smsw), N,
II(SrcMem16 | Mov | Priv, em_lmsw, lmsw),
EXT(0, group7_rm7),
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f980fc43372d..39e61029f401 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6041,6 +6041,7 @@ static const struct __x86_intercept {
[x86_intercept_ins] = POST_EX(SVM_EXIT_IOIO),
[x86_intercept_out] = POST_EX(SVM_EXIT_IOIO),
[x86_intercept_outs] = POST_EX(SVM_EXIT_IOIO),
+ [x86_intercept_xsetbv] = PRE_EX(SVM_EXIT_XSETBV),
};
#undef PRE_EX
--
2.20.1
^ permalink raw reply related
* [PATCH RFC 5/5] x86: KVM: svm: remove hardcoded instruction length from intercepts
From: Vitaly Kuznetsov @ 2019-06-20 11:02 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Jim Mattson
In-Reply-To: <20190620110240.25799-1-vkuznets@redhat.com>
Various intercepts hard-code the respective instruction lengths to optimize
skip_emulated_instruction(): when next_rip is pre-set we skip
kvm_emulate_instruction(vcpu, EMULTYPE_SKIP). The optimization is, however,
incorrect: different (redundant) prefixes could be used to enlarge the
instruction. We can't really avoid decoding.
svm->next_rip is not used when CPU supports 'nrips' (X86_FEATURE_NRIPS)
feature: next RIP is provided in VMCB. The feature is not really new
(Opteron G3s had it already) and the change should have zero affect.
Remove manual svm->next_rip setting with hard-coded instruction lengths. The
only case where we now use svm->next_rip is EXIT_IOIO: the instruction
length is provided to us by hardware.
Reported-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
arch/x86/kvm/svm.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 39e61029f401..4c29859fecde 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2890,13 +2890,11 @@ static int nop_on_interception(struct vcpu_svm *svm)
static int halt_interception(struct vcpu_svm *svm)
{
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 1;
return kvm_emulate_halt(&svm->vcpu);
}
static int vmmcall_interception(struct vcpu_svm *svm)
{
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
return kvm_emulate_hypercall(&svm->vcpu);
}
@@ -3684,7 +3682,6 @@ static int vmload_interception(struct vcpu_svm *svm)
nested_vmcb = map.hva;
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
ret = kvm_skip_emulated_instruction(&svm->vcpu);
nested_svm_vmloadsave(nested_vmcb, svm->vmcb);
@@ -3711,7 +3708,6 @@ static int vmsave_interception(struct vcpu_svm *svm)
nested_vmcb = map.hva;
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
ret = kvm_skip_emulated_instruction(&svm->vcpu);
nested_svm_vmloadsave(svm->vmcb, nested_vmcb);
@@ -3762,7 +3758,6 @@ static int stgi_interception(struct vcpu_svm *svm)
if (vgif_enabled(svm))
clr_intercept(svm, INTERCEPT_STGI);
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
ret = kvm_skip_emulated_instruction(&svm->vcpu);
kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
@@ -3778,7 +3773,6 @@ static int clgi_interception(struct vcpu_svm *svm)
if (nested_svm_check_permissions(svm))
return 1;
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
ret = kvm_skip_emulated_instruction(&svm->vcpu);
disable_gif(svm);
@@ -3803,7 +3797,6 @@ static int invlpga_interception(struct vcpu_svm *svm)
/* Let's treat INVLPGA the same as INVLPG (can be optimized!) */
kvm_mmu_invlpg(vcpu, kvm_rax_read(&svm->vcpu));
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
return kvm_skip_emulated_instruction(&svm->vcpu);
}
@@ -3826,7 +3819,6 @@ static int xsetbv_interception(struct vcpu_svm *svm)
u32 index = kvm_rcx_read(&svm->vcpu);
if (kvm_set_xcr(&svm->vcpu, index, new_bv) == 0) {
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
return kvm_skip_emulated_instruction(&svm->vcpu);
}
@@ -3903,7 +3895,6 @@ static int task_switch_interception(struct vcpu_svm *svm)
static int cpuid_interception(struct vcpu_svm *svm)
{
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 2;
return kvm_emulate_cpuid(&svm->vcpu);
}
@@ -4233,7 +4224,6 @@ static int rdmsr_interception(struct vcpu_svm *svm)
kvm_rax_write(&svm->vcpu, msr_info.data & 0xffffffff);
kvm_rdx_write(&svm->vcpu, msr_info.data >> 32);
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 2;
return kvm_skip_emulated_instruction(&svm->vcpu);
}
}
@@ -4439,7 +4429,6 @@ static int wrmsr_interception(struct vcpu_svm *svm)
return 1;
} else {
trace_kvm_msr_write(ecx, data);
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 2;
return kvm_skip_emulated_instruction(&svm->vcpu);
}
}
--
2.20.1
^ permalink raw reply related
* [PATCH RFC 1/5] x86: KVM: svm: don't pretend to advance RIP in case wrmsr_interception() results in #GP
From: Vitaly Kuznetsov @ 2019-06-20 11:02 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, Paolo Bonzini, Radim Krčmář,
Joerg Roedel, Jim Mattson
In-Reply-To: <20190620110240.25799-1-vkuznets@redhat.com>
svm->next_rip is only used by skip_emulated_instruction() and in case
kvm_set_msr() fails we rightfully don't do that. Move svm->next_rip
advancement to 'else' branch to avoid creating false impression that
it's always advanced.
By the way, rdmsr_interception() has it right already.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5b2ea34bc9f2..982c6b9bfc90 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4430,13 +4430,13 @@ static int wrmsr_interception(struct vcpu_svm *svm)
msr.index = ecx;
msr.host_initiated = false;
- svm->next_rip = kvm_rip_read(&svm->vcpu) + 2;
if (kvm_set_msr(&svm->vcpu, &msr)) {
trace_kvm_msr_write_ex(ecx, data);
kvm_inject_gp(&svm->vcpu, 0);
return 1;
} else {
trace_kvm_msr_write(ecx, data);
+ svm->next_rip = kvm_rip_read(&svm->vcpu) + 2;
return kvm_skip_emulated_instruction(&svm->vcpu);
}
}
--
2.20.1
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v1 12/17] tests/vm: freebsd autoinstall, using serial console
From: Philippe Mathieu-Daudé @ 2019-06-20 10:39 UTC (permalink / raw)
To: Alex Bennée, qemu-devel; +Cc: Fam Zheng, Thomas Huth, Gerd Hoffmann
In-Reply-To: <20190619194021.8240-13-alex.bennee@linaro.org>
On 6/19/19 9:40 PM, Alex Bennée wrote:
> From: Gerd Hoffmann <kraxel@redhat.com>
>
> Instead of fetching the prebuilt image from patchew download the install
> iso and prepare the image locally. Install to disk, using the serial
> console. Create qemu user, configure ssh login. Install packages
> needed for qemu builds.
>
> Note that freebsd package downloads are delivered as non-cachable
> content, so I had to configure squid with "ignore-no-store
> ignore-private ignore-reload" for pkgmir.geo.freebsd.org to make the
> caching actually work.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Tested-by: Thomas Huth <thuth@redhat.com>
> Message-Id: <20190617043858.8290-9-kraxel@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> tests/vm/freebsd | 182 ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 172 insertions(+), 10 deletions(-)
>
> diff --git a/tests/vm/freebsd b/tests/vm/freebsd
> index 091be1a065..2a19461a90 100755
> --- a/tests/vm/freebsd
> +++ b/tests/vm/freebsd
> @@ -2,41 +2,203 @@
> #
> # FreeBSD VM image
> #
> -# Copyright 2017 Red Hat Inc.
> +# Copyright 2017-2019 Red Hat Inc.
> #
> # Authors:
> # Fam Zheng <famz@redhat.com>
> +# Gerd Hoffmann <kraxel@redhat.com>
> #
> # This code is licensed under the GPL version 2 or later. See
> # the COPYING file in the top-level directory.
> #
>
> import os
> +import re
> import sys
> +import time
> +import socket
> import subprocess
> import basevm
>
> class FreeBSDVM(basevm.BaseVM):
> name = "freebsd"
> arch = "x86_64"
> +
> + link = "https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-amd64-disc1.iso.xz"
> + csum = "1d40015bea89d05b8bd13e2ed80c40b522a9ec1abd8e7c8b80954fb485fb99db"
> + size = "20G"
> + pkgs = [
> + # build tools
> + "git",
> + "pkgconf",
> + "bzip2",
> +
> + # gnu tools
> + "bash",
> + "gmake",
> + "gsed",
> + "flex", "bison",
> +
> + # libs: crypto
> + "gnutls",
> +
> + # libs: images
> + "jpeg-turbo",
> + "png",
> +
> + # libs: ui
> + "sdl2",
> + "gtk3",
> + "libxkbcommon",
> +
> + # libs: opengl
> + "libepoxy",
> + "mesa-libs",
> + ]
> +
> BUILD_SCRIPT = """
> set -e;
> - rm -rf /var/tmp/qemu-test.*
> - cd $(mktemp -d /var/tmp/qemu-test.XXXXXX);
> + rm -rf /home/qemu/qemu-test.*
> + cd $(mktemp -d /home/qemu/qemu-test.XXXXXX);
> + mkdir src build; cd src;
> tar -xf /dev/vtbd1;
> - ./configure {configure_opts};
> + cd ../build
> + ../src/configure --python=python3.6 {configure_opts};
> gmake --output-sync -j{jobs} {target} {verbose};
> """
>
> + def console_boot_serial(self):
> + self.console_wait_send("Autoboot", "3")
> + self.console_wait_send("OK", "set console=comconsole\n")
> + self.console_wait_send("OK", "boot\n")
> +
> def build_image(self, img):
> - cimg = self._download_with_cache("http://download.patchew.org/freebsd-11.1-amd64.img.xz",
> - sha256sum='adcb771549b37bc63826c501f05121a206ed3d9f55f49145908f7e1432d65891')
> - img_tmp_xz = img + ".tmp.xz"
> + self.print_step("Downloading install iso")
> + cimg = self._download_with_cache(self.link, sha256sum=self.csum)
> img_tmp = img + ".tmp"
> - sys.stderr.write("Extracting the image...\n")
> - subprocess.check_call(["ln", "-f", cimg, img_tmp_xz])
> - subprocess.check_call(["xz", "--keep", "-dvf", img_tmp_xz])
> + iso = img + ".install.iso"
> + iso_xz = iso + ".xz"
> +
> + self.print_step("Preparing iso and disk image")
> + subprocess.check_call(["cp", "-f", cimg, iso_xz])
> + subprocess.check_call(["xz", "-dvf", iso_xz])
> + subprocess.check_call(["qemu-img", "create", "-f", "qcow2",
> + img_tmp, self.size])
> +
> + self.print_step("Booting installer")
> + self.boot(img_tmp, extra_args = [
> + "-bios", "pc-bios/bios-256k.bin",
> + "-machine", "graphics=off",
> + "-cdrom", iso
> + ])
> + self.console_init()
> + self.console_boot_serial()
> + self.console_wait_send("Console type", "xterm\n")
> +
> + # pre-install configuration
> + self.console_wait_send("Welcome", "\n")
> + self.console_wait_send("Keymap Selection", "\n")
> + self.console_wait_send("Set Hostname", "freebsd\n")
> + self.console_wait_send("Distribution Select", "\n")
> + self.console_wait_send("Partitioning", "\n")
> + self.console_wait_send("Partition", "\n")
> + self.console_wait_send("Scheme", "\n")
> + self.console_wait_send("Editor", "f")
> + self.console_wait_send("Confirmation", "c")
> +
> + self.print_step("Installation started now, this will take a while")
> +
> + # post-install configuration
> + self.console_wait("New Password:")
> + self.console_send("%s\n" % self.ROOT_PASS)
> + self.console_wait("Retype New Password:")
> + self.console_send("%s\n" % self.ROOT_PASS)
> +
> + self.console_wait_send("Network Configuration", "\n")
> + self.console_wait_send("IPv4", "y")
> + self.console_wait_send("DHCP", "y")
> + self.console_wait_send("IPv6", "n")
> + self.console_wait_send("Resolver", "\n")
> +
> + self.console_wait_send("Time Zone Selector", "a\n")
> + self.console_wait_send("Confirmation", "y")
> + self.console_wait_send("Time & Date", "\n")
> + self.console_wait_send("Time & Date", "\n")
> +
> + self.console_wait_send("System Configuration", "\n")
> + self.console_wait_send("System Hardening", "\n")
> +
> + # qemu user
> + self.console_wait_send("Add User Accounts", "y")
> + self.console_wait("Username")
> + self.console_send("%s\n" % self.GUEST_USER)
> + self.console_wait("Full name")
> + self.console_send("%s\n" % self.GUEST_USER)
> + self.console_wait_send("Uid", "\n")
> + self.console_wait_send("Login group", "\n")
> + self.console_wait_send("Login group", "\n")
> + self.console_wait_send("Login class", "\n")
> + self.console_wait_send("Shell", "\n")
> + self.console_wait_send("Home directory", "\n")
> + self.console_wait_send("Home directory perm", "\n")
> + self.console_wait_send("Use password", "\n")
> + self.console_wait_send("Use an empty password", "\n")
> + self.console_wait_send("Use a random password", "\n")
> + self.console_wait("Enter password:")
> + self.console_send("%s\n" % self.GUEST_PASS)
> + self.console_wait("Enter password again:")
> + self.console_send("%s\n" % self.GUEST_PASS)
> + self.console_wait_send("Lock out", "\n")
> + self.console_wait_send("OK", "yes\n")
> + self.console_wait_send("Add another user", "no\n")
> +
> + self.console_wait_send("Final Configuration", "\n")
> + self.console_wait_send("Manual Configuration", "\n")
> + self.console_wait_send("Complete", "\n")
> +
> + self.print_step("Installation finished, rebooting")
> + self.console_boot_serial()
> +
> + # setup qemu user
> + prompt = "$"
> + self.console_ssh_init(prompt, self.GUEST_USER, self.GUEST_PASS)
> + self.console_wait_send(prompt, "exit\n")
> +
> + # setup root user
> + prompt = "root@freebsd:~ #"
> + self.console_ssh_init(prompt, "root", self.ROOT_PASS)
> + self.console_sshd_config(prompt)
> +
> + # setup serial console
> + self.console_wait(prompt)
> + self.console_send("echo 'console=comconsole' >> /boot/loader.conf\n")
> +
> + # setup boot delay
> + self.console_wait(prompt)
> + self.console_send("echo 'autoboot_delay=1' >> /boot/loader.conf\n")
> +
> + # setup virtio-blk #1 (tarfile)
> + self.console_wait(prompt)
> + self.console_send("echo 'chmod 666 /dev/vtbd1' >> /etc/rc.local\n")
> +
> + self.print_step("Configuration finished, rebooting")
> + self.console_wait_send(prompt, "reboot\n")
> + self.console_wait("login:")
> + self.wait_ssh()
> +
> + self.print_step("Installing packages")
> + self.ssh_root_check("pkg install -y %s\n" % " ".join(self.pkgs))
> +
> + # shutdown
> + self.ssh_root(self.poweroff)
> + self.console_wait("Uptime:")
> + self.wait()
> +
> + if os.path.exists(img):
> + os.remove(img)
> os.rename(img_tmp, img)
> + os.remove(iso)
> + self.print_step("All done")
>
> if __name__ == "__main__":
> sys.exit(basevm.main(FreeBSDVM))
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 03/17] tests/vm: pin ubuntu.i386 image
From: Philippe Mathieu-Daudé @ 2019-06-20 10:31 UTC (permalink / raw)
To: Alex Bennée, qemu-devel; +Cc: Fam Zheng, Cleber Rosa
In-Reply-To: <20190619194021.8240-4-alex.bennee@linaro.org>
On 6/19/19 9:40 PM, Alex Bennée wrote:
> From: Cleber Rosa <crosa@redhat.com>
>
> It's a good practice to always have the same components used in tests.
> According to:
>
> https://cloud-images.ubuntu.com/releases/16.04/
>
> New images are released from time to time, and the "release/"
> directory points to the latest release. Let's pin to the latest
> available version, and while at it, set a hash for verification.
>
> Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Message-Id: <20190613130718.3763-4-crosa@redhat.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> tests/vm/ubuntu.i386 | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386
> index 12867b193f..7017e6d388 100755
> --- a/tests/vm/ubuntu.i386
> +++ b/tests/vm/ubuntu.i386
> @@ -61,7 +61,9 @@ class UbuntuX86VM(basevm.BaseVM):
> return os.path.join(cidir, "cloud-init.iso")
>
> def build_image(self, img):
> - cimg = self._download_with_cache("https://cloud-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-i386-disk1.img")
> + cimg = self._download_with_cache(
> + "https://cloud-images.ubuntu.com/releases/16.04/release-20190605/ubuntu-16.04-server-cloudimg-i386-disk1.img",
> + sha256sum="e30091144c73483822b7c27193e9d47346dd1064229da577c3fedcf943f7cfcc")
> img_tmp = img + ".tmp"
> subprocess.check_call(["cp", "-f", cimg, img_tmp])
> subprocess.check_call(["qemu-img", "resize", img_tmp, "50G"])
>
^ permalink raw reply
* Re: [PATCH V10 12/15] arm64: tegra: Enable PCIe slots in P2972-0000 board
From: Thierry Reding @ 2019-06-20 11:01 UTC (permalink / raw)
To: Vidya Sagar
Cc: lorenzo.pieralisi, bhelgaas, robh+dt, mark.rutland, jonathanh,
kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <20190612095339.20118-13-vidyas@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 3012 bytes --]
On Wed, Jun 12, 2019 at 03:23:36PM +0530, Vidya Sagar wrote:
> Enable PCIe controller nodes to enable respective PCIe slots on
> P2972-0000 board. Following is the ownership of slots by different
> PCIe controllers.
> Controller-0 : M.2 Key-M slot
> Controller-1 : On-board Marvell eSATA controller
> Controller-3 : M.2 Key-E slot
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> Changes since [v9]:
> * None
>
> Changes since [v8]:
> * None
>
> Changes since [v7]:
> * None
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * Arranged PCIe nodes in the order of their addresses
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * None
>
> Changes since [v2]:
> * Changed P2U label names to reflect new format that includes 'hsio'/'nvhs'
> strings to reflect UPHY brick they belong to
>
> Changes since [v1]:
> * Dropped 'pcie-' from phy-names property strings
>
> .../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
> .../boot/dts/nvidia/tegra194-p2972-0000.dts | 41 +++++++++++++++++++
> 2 files changed, 42 insertions(+), 1 deletion(-)
Applied to for-5.3/arm64/dt, thanks.
Thierry
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
> index 9f5810765efc..62e07e1197cc 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
> @@ -191,7 +191,7 @@
> regulator-boot-on;
> };
>
> - sd3 {
> + vdd_1v8ao: sd3 {
> regulator-name = "VDD_1V8AO";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <1800000>;
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> index 6e6df650a4b0..eb79663b2af8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> @@ -167,4 +167,45 @@
> };
> };
> };
> +
> + pcie@14100000 {
> + status = "okay";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_hsio_0>;
> + phy-names = "p2u-0";
> + };
> +
> + pcie@14140000 {
> + status = "okay";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_hsio_7>;
> + phy-names = "p2u-0";
> + };
> +
> + pcie@14180000 {
> + status = "okay";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
> + <&p2u_hsio_5>;
> + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3";
> + };
> +
> + pcie@141a0000 {
> + status = "disabled";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>,
> + <&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>,
> + <&p2u_nvhs_6>, <&p2u_nvhs_7>;
> +
> + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4",
> + "p2u-5", "p2u-6", "p2u-7";
> + };
> };
> --
> 2.17.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [linux-lvm] lvm snapshot cannot be removed with the error "Failed to refresh without snapshot"
From: Zdenek Kabelac @ 2019-06-20 11:01 UTC (permalink / raw)
To: LVM general discussion and development, Gang He
In-Reply-To: <5D0B1C6C020000F90006D7B9@prv1-mh.provo.novell.com>
Dne 20. 06. 19 v 7:41 Gang He napsal(a):
> Hello Guys,
>
> Any ideas? or what information do I need to provide to help this problem?
>
Hi
It does look like dmtable had different type of device in place and lvm2
was not able to remove device type.
So was this state a result of some 'regular' workflow you can reproduce?
Or is this some state after some 'vgcfgrestore' usage while some live
LVs were present in table?
Or maybe some incorrectly working error path in code after some failure?
You would probably need to tar /etc/lvm/archive - eventually
open upstream lvm2 community bugzilla:
https://bugzilla.redhat.com/enter_bug.cgi?product=LVM%20and%20device-mapper
and provide steps for reproduction and 'lvmdump -a -m'
Final note - if this bug is happening with some old version of lvm2 - check
first if the newer version isn't already fixed.
Regards
Zdenek
^ permalink raw reply
* Re: [PATCH V10 12/15] arm64: tegra: Enable PCIe slots in P2972-0000 board
From: Thierry Reding @ 2019-06-20 11:01 UTC (permalink / raw)
To: Vidya Sagar
Cc: mark.rutland, devicetree, lorenzo.pieralisi, mperttunen,
mmaddireddy, linux-pci, catalin.marinas, will.deacon,
linux-kernel, kthota, kishon, linux-tegra, robh+dt,
gustavo.pimentel, jingoohan1, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190612095339.20118-13-vidyas@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 3012 bytes --]
On Wed, Jun 12, 2019 at 03:23:36PM +0530, Vidya Sagar wrote:
> Enable PCIe controller nodes to enable respective PCIe slots on
> P2972-0000 board. Following is the ownership of slots by different
> PCIe controllers.
> Controller-0 : M.2 Key-M slot
> Controller-1 : On-board Marvell eSATA controller
> Controller-3 : M.2 Key-E slot
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> Changes since [v9]:
> * None
>
> Changes since [v8]:
> * None
>
> Changes since [v7]:
> * None
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * Arranged PCIe nodes in the order of their addresses
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * None
>
> Changes since [v2]:
> * Changed P2U label names to reflect new format that includes 'hsio'/'nvhs'
> strings to reflect UPHY brick they belong to
>
> Changes since [v1]:
> * Dropped 'pcie-' from phy-names property strings
>
> .../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
> .../boot/dts/nvidia/tegra194-p2972-0000.dts | 41 +++++++++++++++++++
> 2 files changed, 42 insertions(+), 1 deletion(-)
Applied to for-5.3/arm64/dt, thanks.
Thierry
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
> index 9f5810765efc..62e07e1197cc 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
> @@ -191,7 +191,7 @@
> regulator-boot-on;
> };
>
> - sd3 {
> + vdd_1v8ao: sd3 {
> regulator-name = "VDD_1V8AO";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <1800000>;
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> index 6e6df650a4b0..eb79663b2af8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
> @@ -167,4 +167,45 @@
> };
> };
> };
> +
> + pcie@14100000 {
> + status = "okay";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_hsio_0>;
> + phy-names = "p2u-0";
> + };
> +
> + pcie@14140000 {
> + status = "okay";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_hsio_7>;
> + phy-names = "p2u-0";
> + };
> +
> + pcie@14180000 {
> + status = "okay";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
> + <&p2u_hsio_5>;
> + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3";
> + };
> +
> + pcie@141a0000 {
> + status = "disabled";
> +
> + vddio-pex-ctl-supply = <&vdd_1v8ao>;
> +
> + phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>,
> + <&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>,
> + <&p2u_nvhs_6>, <&p2u_nvhs_7>;
> +
> + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4",
> + "p2u-5", "p2u-6", "p2u-7";
> + };
> };
> --
> 2.17.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] samples: make pidfd-metadata fail gracefully on older kernels
From: Dmitry V. Levin @ 2019-06-20 11:00 UTC (permalink / raw)
To: Christian Brauner
Cc: Jann Horn, Oleg Nesterov, Arnd Bergmann, linux-api, linux-kernel
In-Reply-To: <20190620103105.cdxgqfelzlnkmblv@brauner.io>
Cc'ed more people as the issue is not just with the example but
with the interface itself.
On Thu, Jun 20, 2019 at 12:31:06PM +0200, Christian Brauner wrote:
> On Thu, Jun 20, 2019 at 06:11:44AM +0300, Dmitry V. Levin wrote:
> > Initialize pidfd to an invalid descriptor, to fail gracefully on
> > those kernels that do not implement CLONE_PIDFD and leave pidfd
> > unchanged.
> >
> > Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
> > ---
> > samples/pidfd/pidfd-metadata.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c
> > index 14b454448429..ff109fdac3a5 100644
> > --- a/samples/pidfd/pidfd-metadata.c
> > +++ b/samples/pidfd/pidfd-metadata.c
> > @@ -83,7 +83,7 @@ static int pidfd_metadata_fd(pid_t pid, int pidfd)
> >
> > int main(int argc, char *argv[])
> > {
> > - int pidfd = 0, ret = EXIT_FAILURE;
> > + int pidfd = -1, ret = EXIT_FAILURE;
>
> Hm, that currently won't work since we added a check in fork.c for
> pidfd == 0. If it isn't you'll get EINVAL.
Sorry, I must've missed that check. But this makes things even worse.
> This was done to ensure that
> we can potentially extend CLONE_PIDFD by passing in flags through the
> return argument.
> However, I find this increasingly unlikely. Especially since the
> interface would be horrendous and an absolute last resort.
> If clone3() gets merged for 5.3 (currently in linux-next) we also have
> no real need anymore to extend legacy clone() this way. So either wait
> until (if) we merge clone3() where the check I mentioned is gone anyway,
> or remove the pidfd == 0 check from fork.c in a preliminary patch.
> Thoughts?
Userspace needs a reliable way to tell whether CLONE_PIDFD is supported
by the kernel or not.
If CLONE_PIDFD is not supported, then pidfd remains unchanged.
If CLONE_PIDFD is supported and fd 0 is closed, then mandatory pidfd == 0
also remains unchanged, which effectively means that userspace must ensure
that fd 0 is not closed when invoking CLONE_PIDFD. This is ugly.
If we can assume that clone(CLONE_PIDFD) is not going to be extended,
then I'm for removing the pidfd == 0 check along with recommending
userspace to initialize pidfd with -1.
--
ldv
^ permalink raw reply
* [PATCH] dm-verity: Use message limit for data block corruption message.
From: Milan Broz @ 2019-06-20 11:00 UTC (permalink / raw)
To: dm-devel; +Cc: Milan Broz
The dm-verity already uses DMERR_LIMIT on other places, so it
should also limit repeated data block corruption messages.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
---
drivers/md/dm-verity-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 720d06531aa3..08f83e160ad5 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -235,7 +235,7 @@ static int verity_handle_err(struct dm_verity *v, enum verity_block_type type,
BUG();
}
- DMERR("%s: %s block %llu is corrupted", v->data_dev->name, type_str,
+ DMERR_LIMIT("%s: %s block %llu is corrupted", v->data_dev->name, type_str,
block);
if (v->corrupted_errs == DM_VERITY_MAX_CORRUPTED_ERRS)
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.