On 02/12/15 17:10, Boris Ostrovsky wrote:
> Resuming PMU currently triggers a warning from ___might_sleep() (assuming
> CONFIG_DEBUG_ATOMIC_SLEEP is set) when xen_pmu_init() allocates GFP_KERNEL
> page because we are in state resembling atomic context.
>
> Move resuming PMU to xen_arch_resume()
On 10/11/15 20:10, Boris Ostrovsky wrote:
> Doing so will cause the grant to be unmapped and then, during
> fault handling, the fault to be mistakenly treated as NUMA hint
> fault.
>
> In addition, even if those maps could partcipate in NUMA
> balancing, it wouldn't provide any benefit since we
o what the problem is and
> eliminates false expectations.
>
> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
> Signed-off-by: David Vrabel <david.vra...@citrix.com>
> Signed-off-by: Kamal Mostafa <ka...@canonical.com>
> ---
> arch/x86/xen/enlighten.c |
On 13/10/15 23:59, gre...@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> x86/xen: Support kexec/kdump in HVM guests by doing a soft reset
>
> to the 4.2-stable tree which can be found at:
>
>
On 08/10/15 23:14, Ben Hutchings wrote:
> On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
>> [resending to correct stable address, sorry folks]
>>
>> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
>> ("xen/gntdev: convert priv->lock to a mutex", which was added in
On 12/10/15 13:56, Ben Hutchings wrote:
> On Mon, 2015-10-12 at 11:11 +0100, David Vrabel wrote:
>> On 08/10/15 23:14, Ben Hutchings wrote:
>>> On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
>>>> [resending to correct stable address, sorry folks]
On 03/09/15 12:05, Luis Henriques wrote:
> On Wed, Sep 02, 2015 at 10:18:32AM +0100, Ian Campbell wrote:
>> [resending to correct stable address, sorry folks]
>>
>> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
>> ("xen/gntdev: convert priv->lock to a mutex", which was
On 27/08/15 18:15, Marek Marczykowski-Górecki wrote:
On Thu, Aug 27, 2015 at 11:37:44AM -0400, Sasha Levin wrote:
From: Marek Marczykowski-Górecki marma...@invisiblethingslab.com
This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.
On 3.18 it
The commit causes WARNING spam and has been reverted. Please don't backport.
David
From: gre...@linuxfoundation.org [gre...@linuxfoundation.org]
Sent: 14 August 2015 01:44
To: Ross Lagerwall; David Vrabel; gre...@linuxfoundation.org
Cc: stable
On 10/08/15 14:40, Jason A. Donenfeld wrote:
It turns out that domU also requires the Xen APIC driver. Otherwise we
get stuck in busy loops that never exit, such as in this stack trace:
Applied to for-linus-4.2 and tagged for stable, thanks.
David
--
To unsubscribe from this list: send the
On 10/08/15 14:40, Jason A. Donenfeld wrote:
It turns out that domU also requires the Xen APIC driver. Otherwise we
get stuck in busy loops that never exit, such as in this stack trace:
What's the difference between v3 and v2?
David
--
To unsubscribe from this list: send the line unsubscribe
going on.
This isn't a great long-term fix. This code should probably be
changed to use something like set_memory_ro.
Reviewed-by: David Vrabel david.vra...@citrix.com
Thanks.
David
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord
patch_site:
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
Acked-by: David Vrabel david.vra...@citrix.com
Thanks.
David
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
using the the wrong L3 offset for
level2_kernel_pgt. These have been corrected.
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
Cc: stable@vger.kernel.org
Signed-off-by: David Vrabel david.vra...@citrix.com
---
Changes in v3:
- Improve commit message.
Changes in v2:
- Convert
On 04/08/14 19:42, Konrad Rzeszutek Wilk wrote:
On Mon, Jul 28, 2014 at 02:06:59PM +0100, David Vrabel wrote:
On 14/07/14 17:18, Konrad Rzeszutek Wilk wrote:
As commit 0a9fd0152929db372ff61b0d6c280fdd34ae8bdb
'xen/pciback: Document the entry points for 'pcistub_put_pci_dev''
explained
is for a rather specific and uncommon use case (manually
unbinding a PCI while it is passed-through). Is this critical enough to
warrant a stable backport?
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: David Vrabel david.vra
On 10/06/14 01:25, Greg Kroah-Hartman wrote:
3.4-stable review patch. If anyone has any objections, please let me know.
This is a new feature and not a bug fix. I don't think it (and patches
83-85) are suitable for stable.
David
--
To unsubscribe from this list: send the line unsubscribe
On 10/06/14 10:30, Daniel Kiper wrote:
On Tue, Jun 10, 2014 at 10:07:27AM +0100, David Vrabel wrote:
On 10/06/14 01:25, Greg Kroah-Hartman wrote:
3.4-stable review patch. If anyone has any objections, please let me know.
This is a new feature and not a bug fix. I don't think it (and patches
On 23/05/14 10:05, Jiri Slaby wrote:
From: Vladimir Murzin murzi...@gmail.com
This patch does NOT apply to the 3.12 stable tree. If you still want
it applied, please provide a backport.
This patch is only for 3.14 and later.
David
--
To unsubscribe from this list: send the line unsubscribe
On 10/04/14 11:05, Steven Noonan wrote:
I realize it's late to protest on this given that 3.13.9 is out, but
what is the path forward for those experiencing the original issue
that the reverted commit was intended to correct?
Disable NUMA_REBALANCING.
Or apply
On 04/04/14 19:48, kon...@kernel.org wrote:
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
The git commit a945928ea2709bc0e8e8165d33aed855a0110279
('xen: Do not enable spinlocks before jump_label_init() has executed')
was added to deal with the jump machinery. Earlier the code
that
On 20/02/14 20:13, Greg Kroah-Hartman wrote:
On Thu, Feb 20, 2014 at 10:51:24AM +, David Vrabel wrote:
These two changes fix important bugs with 32-bit Xen PV guests.
0160676bba69523e8b0ac83f306cce7d342ed7c8 (xen/p2m: check MFN is in range
before using the m2p table)
Now applied
On 20/02/14 20:08, gre...@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 3.13-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/stable_kernel_rules.txt.
I could be totally wrong, and if so, please respond to
On 21/02/14 15:21, Greg KH wrote:
On Fri, Feb 21, 2014 at 10:35:48AM +, David Vrabel wrote:
On 20/02/14 20:08, gre...@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 3.13-stable tree.
I fail to see how this patch meets the stable kernel rules as found
These two changes fix important bugs with 32-bit Xen PV guests.
0160676bba69523e8b0ac83f306cce7d342ed7c8 (xen/p2m: check MFN is in range
before using the m2p table)
7cde9b27e7b3a2e09d647bb4f6d94e842698d2d5 (xen: Fix possible user space
selector corruption)
Please apply to 3.10.y.
Thanks.
From: David Vrabel david.vra...@citrix.com
Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED. If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.
So, treat an unexpected backend CLOSED state
3.10.18 included 279f438e36c0 (xen-netback: Don't destroy the netdev
until the vif is shut down) but this has a regression that was fixed by
dc62ccaccfb1 (xen-netback: transition to CLOSED when removing a VIF)
dc62ccaccfb1 depends on ea732dff5cfa (xen-netback: Handle backend state
transitions in
On 11/10/13 11:42, Luis Henriques wrote:
3.5.7.23 -stable review patch. If anyone has any objections, please let me
know.
It's harmless to backport this, but it is only needed in 3.10 and later
(unless you've backported d0380e6c).
From: David Vrabel david.vra...@citrix.com
commit
From: David Vrabel david.vra...@citrix.com
Commit d0380e6c3c0f6edb986d8798a23acfaf33d5df23 (early_printk:
consolidate random copies of identical code) added in 3.10 introduced
a check for con-index == -1 in early_console_register().
Initialize index to -1 for the xenboot console so earlyprintk
From: David Vrabel david.vra...@citrix.com
If there are UNUSABLE regions in the machine memory map, dom0 will
attempt to map them 1:1 which is not permitted by Xen and the kernel
will crash.
There isn't anything interesting in the UNUSABLE region that the dom0
kernel needs access to so we can
On 09/07/13 15:13, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 09, 2013 at 02:38:53PM +0100, David Vrabel wrote:
From: David Vrabel david.vra...@citrix.com
If there are UNUSABLE regions in the machine memory map, dom0 will
attempt to map them 1:1 which is not permitted by Xen and the kernel
-- original commit in Linus's tree --
From 0e367ae46503cfe7791460c8ba8434a5d60b2bd5 Mon Sep 17 00:00:00 2001
From: David Vrabel david.vra...@citrix.com
Date: Thu, 7 Mar 2013 17:32:01 +
Subject: [PATCH] xen/blkback: correctly respond to unknown, non-native
requests
From: David Vrabel david.vra...@citrix.com
In unmask_evtchn(), when the mask bit is cleared after testing for
pending and the event becomes pending between the test and clear, then
the upcall will not become pending and the event may be lost or
delayed.
Avoid this by always clearing the mask bit
From: David Vrabel david.vra...@citrix.com
In unmask_evtchn(), when the mask bit is cleared after testing for
pending and the event becomes pending between the test and clear, then
the upcall will not become pending and the event may be lost or
delayed.
Avoid this by always clearing the mask bit
From: David Vrabel david.vra...@citrix.com
In unmask_evtchn(), when the mask bit is cleared after testing for
pending and the event becomes pending between the test and clear, then
the upcall will not become pending and the event may be lost or
delayed.
Avoid this by always clearing the mask bit
From: David Vrabel david.vra...@citrix.com
If the frontend is using a non-native protocol (e.g., a 64-bit
frontend with a 32-bit backend) and it sent an unrecognized request,
the request was not translated and the response would have the
incorrect ID. This may cause the frontend driver to behave
On 04/03/13 09:57, Jan Beulich wrote:
On 01.03.13 at 18:33, David Vrabel david.vra...@citrix.com wrote:
If the frontend is using a non-native protocol (e.g., a 64-bit
frontend with a 32-bit backend) and it sent an unrecognized request,
the request was not translated and the response would have
From: David Vrabel david.vra...@citrix.com
If the frontend is using a non-native protocol (e.g., a 64-bit
frontend with a 32-bit backend) and it sent an unrecognized request,
the request was not translated and the response would have the
incorrect ID. This may cause the frontend driver to behave
auditing is
enabled.
David (Cc-ed) came up with an identical fix, so likely this can
be taken to count as an ack from him.
Reported-by: Peter Moody pmo...@google.com
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w
On 08/02/2013 20:34, Tim Gardner wrote:
This buffer overflow was introduced with
91e0c5f3dad47838cb2ecc1865ce789a0b7182b1
(2.6.24).
There's no buffer overflow here. xen_mc_flush() resets b-cbidx.
David
arch/x86/xen/multicalls.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On 25/01/13 18:43, Konrad Rzeszutek Wilk wrote:
Check that the ring does not have an insane amount of requests
(more than there could fit on the ring).
[...]
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
[...]
@@ -415,8 +415,12 @@ int
On 28/01/13 15:44, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 28, 2013 at 11:38:50AM +, David Vrabel wrote:
On 25/01/13 18:43, Konrad Rzeszutek Wilk wrote:
Check that the ring does not have an insane amount of requests
(more than there could fit on the ring).
[...]
--- a/drivers/block/xen
From: David Vrabel david.vra...@citrix.com
map-kmap_ops allocated in gntdev_alloc_map() wasn't freed by
gntdev_put_map().
Add a gntdev_free_map() helper function to free everything allocated
by gntdev_alloc_map().
Signed-off-by: David Vrabel david.vra...@citrix.com
Cc: stable@vger.kernel.org
On 19/10/12 16:29, Jan Beulich wrote:
On 17.10.12 at 15:29, David Vrabel david.vra...@citrix.com wrote:
From: David Vrabel david.vra...@citrix.com
In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
From: David Vrabel david.vra...@citrix.com
In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after
From: David Vrabel david.vra...@citrix.com
In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after
46 matches
Mail list logo
