Assuming you're just using git for conveniently applying local
downstream patches, you don't need the git repo to exist once
getting to the build stage. IOW just delete the .git dir after
applying patches before running a build.
...then what do you do if the build fails and you want to
ed
I just pushed/uploaded a SRU for bionic from:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/387269
Waiting for SRU on it.
** Changed in: qemu (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this
** Description changed:
+
+ SRU TEAM REVIEWER: This has already been SRUed for Focal, Eoan and Bionic.
Unfortunately the Bionic SRU did not work and we had to reverse the change.
Since then we had another update and now I'm retrying the SRU.
+
+ After discussing with @paelzer (and @dannf as a
qemu (1:5.0-5ubuntu3) groovy; urgency=medium
has the merge with this fix:
- linux-user-add-netlink-RTM_SETLINK-command.patch (Closes: #964289)
** Changed in: qemu (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml,
Status from old attempts to solve same nature issues:
Older (2018) merge request from @raharper:
https://github.com/koverstreet/bcache-tools/pull/1
addressing the fact that kernel uevents would not always emit
CACHED_UUID parameters, making udev to delete (whenever that happens)
/dev/bca
I've hidden last post as it was posted in the wrong bug.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rcu_call_ready_event logic in Aarch64 when
converting image
Thanks @dannf! I spoke to Christian and him and I agreed to confine this
change into ARM builds only (as SRU for Bionic). Preparing it...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
Worked being done for the Bionic SRU:
BUG: https://bugs.launchpad.net/qemu/+bug/1805256
(fix for the bionic regression demonstrated at LP: #1885419)
PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1805256-bionic
MERGE: https://tinyurl.com/y8sucs6x
Merge proposal currently going under
Started working on this again...
** Changed in: qemu (Ubuntu Bionic)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rcu_call_r
Hello Alexander,
I believe your fuzz test result was meant to the upstream project so I
moved it.
o/
** Also affects: qemu
Importance: Undecided
Status: New
** No longer affects: qemu-kvm (Ubuntu)
--
You received this bug notification because you are a member of qemu-
devel-ml, whic
FYIO, from now on all the "merge" work will be done in the merge
requests being linked to this BUG (at the top). @paelzer will be
verifying those.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
** Description changed:
+ [Impact]
+
+ * QEMU locking primitives might face a race condition in QEMU Async I/O
+ bottom halves scheduling. This leads to a dead lock making either QEMU
+ or one of its tools to hang indefinitely.
+
+ [Test Case]
+
+ * qemu-img convert -f qcow2 -O qcow2 ./disk01.q
** Changed in: qemu (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: qemu
Status: In Progress => Fix Released
** Changed in: qemu (Ubuntu Focal)
Status: Incomplete => In Progress
** Changed in: qemu (Ubuntu Eoan)
Status: I
Hello Ike,
Please, let me know if you want me to go after the needed SRUs for this
fix or if you will.
I'll wait for the final feedback from tests with your PPA.
Cheers!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.
** Changed in: qemu (Ubuntu Eoan)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: qemu
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscri
Hello Fred,
Based on Dann's feedback on testing, I'm failing to see where your patch
fixes the "root" cause (despite being able to mitigate the issue by
changing the aio notification mechanism).
I think the root cause is best described in this 2 emails from the
thread:
https://lore.kernel.org/qe
On 02/10/19 16:58, Torvald Riegel wrote:
> This example looks like Dekker synchronization (if I get the intent right).
It is the same pattern. However, one of the two synchronized variables
is a counter rather than just a flag.
> Two possible implementations of this are either (1) with all memor
On Wed, 2019-10-02 at 15:20 +0200, Paolo Bonzini wrote:
> On 02/10/19 13:05, Jan Glauber wrote:
>> The arm64 code generated for the
>> atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
>> memory barriers. It is just plain ldaxr/stlxr.
>>
>> From my understanding this is not sufficient
Documenting this here as bug# was dropped from the mail thread:
On 02/10/19 13:05, Jan Glauber wrote:
> The arm64 code generated for the
> atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
> memory barriers. It is just plain ldaxr/stlxr.
>
> From my understanding this is not sufficie
>>> There are times when the main loop can get blocked even though the CPU
>>> threads can be running and can in some configurations perform IO
>>> even without the main loop (I think!).
>> Ah, that's a very good point. Indeed, you can perform IO in those
>> cases specially when using vhost devic
** Also affects: qemu (Ubuntu Ff-series)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Eoan)
Importance: Medium
Assignee: Rafael David Tinoco (rafaeldtinoco)
Status: In
> Zhengui's theory that notify_me doesn't work properly on ARM is more
> promising, but he couldn't provide a clear explanation of why he thought
> notify_me is involved. In particular, I would have expected notify_me to
> be wrong if the qemu_poll_ns call came from aio_ctx_dispatch, for example:
> Note that the RCU thread is expected to sit most of the time doing
> nothing, so I don't think this matters.
Agreed.
> Zhengui's theory that notify_me doesn't work properly on ARM is more
> promising, but he couldn't provide a clear explanation of why he thought
> notify_me is involved. In
** Description changed:
+ Command:
+
+ qemu-img convert -m 1 -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2
+
+ Hangs indefinitely approximately 30% of the runs.
+
+
+
+ Workaround:
+
+ qemu-img convert -m 1 -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2
+
+ Run "qemu-img convert" wit
Quick update...
> value INT_MAX (4294967295) seems WRONG for qemu_futex_wait():
>
> - EV_BUSY, being -1, and passed as an argument qemu_futex_wait(void *,
> unsigned), is a two's complement, making argument into a INT_MAX when
> that's not what is expected (unless I missed something).
>
> *** If
In comment #14, please disregard the second half of the issue, related
to:
0xaabd4100 <+16>: cbz w1, 0xaabd4108
0xaabd4104 <+20>: ret
0xaabd4108 <+24>: ldaxr w1, [x0]
0xaabd410c <+28>: orr w1, w1, #0x1
=> 0xaabd4110 <+32>
Paolo,
While debugging hungs in ARM64 while doing a simple:
qemu-img convert -f qcow2 -O qcow2 file.qcow2 output.qcow2
I might have found 2 issues which I'd like you to review, if possible.
ISSUE #1
I've caught the following stack trace after an HUNG in qemu-img convert:
(gdb) bt
#0
QEMU BUG: #1
Alright, one of the issues is (according to comment #14):
"""
Meaning that code is waiting for a futex inside kernel.
(gdb) print rcu_call_ready_event
$4 = {value = 4294967295, initialized = true}
The QemuEvent "rcu_call_ready_event->value" is set to INT_MAX and I
don't know why ye
** Summary changed:
- qemu-img hangs on high core count ARM system
+ qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images
** Changed in: qemu
Status: Confirmed => In Progress
** Changed in: qemu
Assignee: (unassigned) => Rafael David Tinoco (rafaeld
Alright, here is what is happening:
Whenever program is stuck, thread #2 backtrace is this:
(gdb) bt
#0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
#1 0xaabd41b0 in qemu_futex_wait (val=, f=) at ./util/qemu-thread-posix.c:438
#2 qemu_event_wait (ev=ev@entry=0xaac8
Alright,
I'm still investigating this but wanted to share some findings... I
haven't got a kernel dump yet after the task is frozen, I have analyzed
only the userland part of it (although I have checked if code was
running inside kernel with perf cycles:u/cycles:k at some point).
The big picture
Alright, with a d06 aarch64 machine I was able to reproduce it after 8
attempts.I'll debug it today and provide feedback on my findings.
(gdb) bt full
#0 0xb0b2181c in __GI_ppoll (fds=0xce5ab770, nfds=4,
timeout=, timeout@entry=0x0,
sigmask=sigmask@entry=0x0) at ../sysdeps/unix/s
Alright, I couldn't reproduce this yet, I'm running same test case in a
24 cores box and causing lots of context switches and CPU migrations in
parallel (trying to exhaust the logic).
Will let this running for sometime to check.
Unfortunately this can be related QEMU AIO BH locking/primitives and
OOhh nm on the virtual environment test, as I just remembered we don't
have KVM on 2nd level for aarch64 yet (at least in ARMv8 implementing
virt extension). I'll try to reproduce in the real env only.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subs
Hello Liz,
I'll try to reproduce this issue in a Cortex-A53 aarch64 real
environment (w/ 24 HW threads) AND in a virtual environment w/ lots of
vCPUs... but, if it's a barrier missing - or the lack of atomicity
and/or ordering in a primitive - then, I'm afraid the context switch in
between vCPUs m
** Changed in: qemu (Ubuntu)
Status: Confirmed => In Progress
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
** Changed in: qemu (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a
Avi,
Something I have realized we missed as a feedback here - or maybe I
missed checking previous comments - is how your mouse is being setup for
the guest. Is it being PS/2 emulated (default) or is it being given as
an USB device (when qemu cmd line has "-usb -device usb-tablet"). Also,
are you u
*** This bug is a duplicate of bug 1828495 ***
https://bugs.launchpad.net/bugs/1828495
Commit:
https://bugs.launchpad.net/intel/+bug/1828495/comments/42
Addresses exactly this bug fix.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
*** This bug is a duplicate of bug 1828495 ***
https://bugs.launchpad.net/bugs/1828495
I'm marking this bug as a duplicate of LP: #1828495 since both are
asking for mitigations pass-through to i386 kvm guests and I'm preparing
a fix for both simultaneously.
** This bug has been marked a dupli
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830821
Title:
Expose ARCH_CAP_MDS_NO in guest
This effort, if done, would be done together with:
https://bugs.launchpad.net/intel/+bug/1828495
Please read comments:
https://bugs.launchpad.net/intel/+bug/1828495/comments/8
and
https://bugs.launchpad.net/intel/+bug/1828495/comments/10
--
You received this bug notification because you are
For Mitaka, this bug will be included in UCA together with the fix for:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1656480
When it becomes available.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.ne
*** This bug is a duplicate of bug 1317491 ***
https://bugs.launchpad.net/bugs/1317491
Upstream "fixed" the issue - by finishing "block-commit" - in v1.3. That
is why I'm marking this bug as a duplicate of the Ubuntu bug. I'll
provide more comments in that bug.
** This bug has been marked a d
Thanks Christian! Will do!!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972
Title:
QEMU memfd_create fallback mechanism change for security drivers
Status in Ubuntu Cloud Archive:
Invalid
For me we had enough tests already. Upstream development/tests, Zesty,
Yakkety. Christian, could you please move Xenial for me ? I have some
end users waiting for this. Thank you very much.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Yakkety Verification (with 3.13 kernel from Trusty since a <= 3.17
kernel is needed). This verifies that Ubuntu Cloud Archive repositories
will be alright with this new packages (from Xenial / Yakkety).
## CURRENT
inaddy@(ykvm01):~$ apt-cache policy qemu-kvm
qemu-kvm:
Installed: 1:2.6.1+dfsg-0u
Xenial Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel
is needed). This verifies that Ubuntu Cloud Archive repositories will be
alright with this new packages (from Xenial / Yakkety).
## CURRENT
inaddy@(xkvm01):~$ apt-cache policy qemu-kvm
qemu-kvm:
Installed: 1:2.5+dfsg-5ubun
@jamespage, @cpaelzer,
I'll verify this fix in couple of days so it can be released.
Thank you!
Rafael
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972
Title:
QEMU memfd_create fallback mec
Hello Antonio (@arcimboldo)
The fix only makes sense for newer QEMUs (>= Xenial, like the one from
Mitaka Ubuntu Cloud Archive).
OBS:
The "migration check" is done in VHOST initialization functions when the
devices are virtually attached to the virtual machine. If you are using
kernel 3.13 and h
** Patch added: "zesty_qemu_2.6.1+dfsg-0ubuntu7.debdiff"
https://bugs.launchpad.net/qemu/+bug/1626972/+attachment/4781485/+files/zesty_qemu_2.6.1+dfsg-0ubuntu7.debdiff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.l
** Description changed:
- And, when libvirt starts using apparmor, and creating apparmor profiles
- for every virtual machine created in the compute nodes, mitaka qemu (2.5
- - and upstream also) uses a fallback mechanism for creating shared
- memory for live-migrations. This fall back mechanism,
Right now Zesty is behind Yakkety because of a Security Update. Not sure
you need me to attach a debdiff for Zesty as well. Let me know.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972
Title:
Took some more time here because of LP: #1621269.
** Patch added: "yakkety_qemu_2.6.1+dfsg-0ubuntu5.2.debdiff"
https://bugs.launchpad.net/qemu/+bug/1626972/+attachment/4781464/+files/yakkety_qemu_2.6.1+dfsg-0ubuntu5.2.debdiff
--
You received this bug notification because you are a member of
Thanks Christian,
Then I'll finish this SRU first. Will work in the vhost mmap log file
right after.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972
Title:
QEMU memfd_create fallback mechani
** Patch added: "xenial_qemu_2.5+dfsg-5ubuntu10.7.debdiff"
https://bugs.launchpad.net/qemu/+bug/1626972/+attachment/4781425/+files/xenial_qemu_2.5+dfsg-5ubuntu10.7.debdiff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bu
** Changed in: cloud-archive
Status: New => In Progress
** Changed in: cloud-archive
Assignee: (unassigned) => Rafael David Tinoco (inaddy)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.ne
till cause migration problems, but, likely, those are the vast
minority.
commit 0d34fbabc13891da41582b0823867dc5733fffef
Author: Rafael David Tinoco
Date: Mon Oct 24 15:35:03 2016 +
vhost: migration blocker only if shared log is used
Commit 31190ed7 added a migration blocker in vhost_dev
** Changed in: qemu (Ubuntu Xenial)
Status: New => In Progress
** Changed in: qemu (Ubuntu Yakkety)
Status: New => In Progress
** Changed in: qemu (Ubuntu Xenial)
Assignee: (unassigned) => Rafael David Tinoco (inaddy)
** Changed in: qemu (Ubuntu Yakkety)
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => In Progress
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (inaddy)
--
You received this bug notification because you are a mem
Hello,
> On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco
> wrote:
> Hello Michael, André,
>
> Could you do a quick review before a final submission ?
>
> http://paste.ubuntu.com/23446279/
> ...
> (André) > Could it be only a filename? This would simpli
Is there anything else ?
Thank you
Rafael Tinoco
On Mon, Oct 31, 2016 at 8:30 PM, Michael S. Tsirkin wrote:
> On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote:
>> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin wrote:
>> >
>> > On Sat, Oct 22
On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin wrote:
>
> On Sat, Oct 22, 2016 at 07:00:41AM +, Rafael David Tinoco wrote:
> > Commit 31190ed7 added a migration blocker in vhost_dev_init() to
> > check if memfd would succeed. It is better if this blocker first
> >
doesn't support it).
Signed-off-by: Rafael David Tinoco
Reviewed-by: Marc-André Lureau
---
hw/virtio/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index bd051ab..742d0aa 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vh
> Begin forwarded message:
>
> From: Rafael David Tinoco
> Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using
> argv paremeter
> Date: October 22, 2016 at 19:52:31 GMT-2
> To: Marc-André Lureau
> Cc: Rafael David Tinoco , qemu-devel
>
> Begin forwarded message:
>
> From: Marc-André Lureau
> Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using
> argv paremeter
> Date: October 22, 2016 at 05:18:02 GMT-2
> To: Rafael David Tinoco
> Cc: QEMU
>
> Hi
>
> On Sat, O
Hello,
> On Oct 22, 2016, at 05:18, Marc-André Lureau
> wrote:
>
> Hi
>
> On Sat, Oct 22, 2016 at 10:01 AM Rafael David Tinoco
> wrote:
> Commit 31190ed7 added a migration blocker in vhost_dev_init() to
> check if memfd would succeed. It is better if this bloc
Commit 31190ed7 added a migration blocker in vhost_dev_init() to
check if memfd would succeed. It is better if this blocker first
checks if vhost backend requires shared log. This will avoid a
situation where a blocker is added inappropriately (e.g. shared
log allocation fails when vhost backend do
-existent,
or a directory, random files are going to be created in the specified
directory (or, for non-existent, in tmpdir). If vhostlog is specified,
the filepath is always used when allocating vhost log files.
Signed-off-by: Rafael David Tinoco
---
hw/net/vhost_net.c| 4 +-
hw/sc
apparmor labelling on tmp files (and
because file descriptors can be passed away, like we discussed before).
If that is okay I'll provide a patch asap. Let me know if you prefer something
else.
Thank you,
Rafael
> On Oct 04, 2016, at 12:29, Rafael David Tinoco
> wrote:
>
>
more.
> On Oct 21, 2016, at 01:03, Rafael David Tinoco
> wrote:
>
> Also, if possible, I would like comments about a draft:
>
> https://pastebin.canonical.com/168579/
> (please disregard printfs and minor problems)
> On Oct 04, 2016, at 10:50, Marc-André Lureau
> wrote:
>
> What about having a single config parameter as a place to put all vhost logs
> for all drives for a single instance ? Remove the memfd implementation with
> all the memfd shared_memory option ? Replace it with a
> open+unlink+ftrunc
> On Oct 04, 2016, at 10:10, Marc-André Lureau
> wrote:
>
> > How will this path be used? Is it going to be global to qemu for various
> > use (kinda like $TMP), or per-device, or for memfd fallback only? Should
> > the path pre-exist? (I suppose, if not, qemu should clean it up when
> > leavin
True.
What about having a single config parameter as a place to put all vhost logs
for all drives for a single instance ? Remove the memfd implementation with all
the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap
approach only.
This way every device would get its o
Let me work on it. I'll get back soon.
Tks Daniel.
> On Oct 04, 2016, at 05:36, Daniel P. Berrange wrote:
>
> On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote:
>> Yes, definitely. Check this:
>
> [snip]
>
> So in that case, I think w
ing implemented:
vhost_user_set_log_base -> VhostUserMsg = VHOST_USER_SET_LOG_BASE
vhost_user_write(with the VHOST_USER_GET_LOG_BASE message):
- configures the file descriptors(... , fds, fd_num)
qemu_chr_fe_set_msgfds
- writes them down the char driver
qemu_chr_fe_write_all
> On Oct 03, 2016, at 15:46
Hello Daniel,
> On Oct 03, 2016, at 14:55, Daniel P. Berrange wrote:
>
>> Well, it unlinks the file but the references are still there while the
>> descriptor isn't closed by this process, or by the one that receives the
>> descriptor (that is why is the "unlink" so early).
>>
>> If you check v
Hello Marc,
> On Sep 27, 2016, at 08:13, Marc-André Lureau wrote:
>
>>> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote:
>>> We should not have QEMU creating unpredictabile filenames in the
>>> first place - any filenames should be det
Sorry, I was only able to come back to this today.
> On Sep 27, 2016, at 09:18, Daniel Berrange <1626...@bugs.launchpad.net> wrote:
>
>> There are numerous people relying on older kernels in openstack
>> deployments - sometimes with specific drivers (ovswitch, dpdk,
>> infiniband) holding kerne
Hello!
> On Sep 27, 2016, at 08:13, Marc-André Lureau wrote:
>
>> Note that the filename, per se, is not as important as other files,
>> since qemu won't provide it for being accessed by external programs, and,
>> deletes the file, while keeping the descriptor, right after its creation
>> (due t
> On Sep 27, 2016, at 05:36, Daniel P. Berrange wrote:
>
> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote:
>> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback
>> mechanism for systems not supporting memfd_create syscall (started
>
I'll follow to see if patch was accepted upstream:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06191.html
https://www.mail-archive.com/qemu-devel@nongnu.org/msg400892.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
pid=74648
comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107
ouid=107
Signed-off-by: Rafael David Tinoco
---
util/memfd.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/util/memfd.c b/util/memfd.
pid=74648
comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107
ouid=107
Signed-off-by: Rafael David Tinoco
---
util/memfd.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/util/memfd.c b/util/memfd.
Fixed it according to checkpatch.pl as stated in
http://wiki.qemu.org/Contribute/SubmitAPatch.
http://paste.ubuntu.com/23220104/
Will submit to mailing list after testing everything.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
h
roved it a little bit: http://paste.ubuntu.com/23217333/
And fixed it:
http://paste.ubuntu.com/23219599/
(Probable the version to be suggested to upstream)
** Changed in: qemu
Status: New => In Progress
** Changed in: qemu
Assignee: (unassigned) => Rafael David Tinoco (inaddy)
Related: https://bugs.launchpad.net/nova/+bug/1613423
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972
Title:
QEMU memfd_create fallback mechanism change for security drivers
Status in QEMU:
bvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/var/tmp/"
pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107
ouid=0
When leaving libvirt without apparmor capabilities (thus not confining
virtual machines on comput
87 matches
Mail list logo