Re: [PATCH] xen/events: don't use chip_data for legacy IRQs

30fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to > store a per interrupt XEN data pointer which contains XEN specific > information.") > Signed-off-by: Juergen Gross Tested-by: Stefan Bader > --- > drivers/xen/events/events_base.c | 29 +-

Re: [PATCH 4.4 50/62] XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.

On 29.09.20 16:05, Jürgen Groß wrote: > On 29.09.20 15:13, Stefan Bader wrote: >> On 01.09.20 17:10, Greg Kroah-Hartman wrote: >>> From: Thomas Gleixner >>> >>> commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream. >>> >>> handler data i

Re: [PATCH 4.4 50/62] XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.

On 29.09.20 16:05, Jürgen Groß wrote: > On 29.09.20 15:13, Stefan Bader wrote: >> On 01.09.20 17:10, Greg Kroah-Hartman wrote: >>> From: Thomas Gleixner >>> >>> commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream. >>> >>> handler data i

Re: [PATCH 4.4 50/62] XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.

On 01.09.20 17:10, Greg Kroah-Hartman wrote: > From: Thomas Gleixner > > commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream. > > handler data is meant for interrupt handlers and not for storing irq chip > specific information as some devices require handler data to store internal > per

Re: [PATCH 1/4] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes

On 29.05.19 12:37, Greg KH wrote: > On Wed, May 29, 2019 at 12:25:39PM +0200, Stefan Bader wrote: >> From: Jiri Wiesner >> >> The *_frag_reasm() functions are susceptible to miscalculating the byte >> count of packet fragments in case the truesize of a head buffer chan

Re: [PATCH 1/4] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes

On 29.05.19 12:37, Greg KH wrote: > On Wed, May 29, 2019 at 12:25:39PM +0200, Stefan Bader wrote: >> From: Jiri Wiesner >> >> The *_frag_reasm() functions are susceptible to miscalculating the byte >> count of packet fragments in case the truesize of a head buffer chan

[PATCH 0/4] ipv6: frags: fixups for linux-4.4.y

g_queue() Jiri Wiesner (1): ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes Peter Oskolkov (2): ip: fail fast on IP defrag errors net: IP defrag: encapsulate rbtree defrag code into callable functions Stefan Bader (1): ipv6: frags: Use inet_frag_pull

[PATCH 1/4] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes

djustments in net/ipv6/netfilter/nf_conntrack_reasm.c] Signed-off-by: Stefan Bader --- net/ipv4/ip_fragment.c | 7 +++ net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +++- net/ipv6/reassembly.c | 8 +++- 3 files changed, 21 insertions(+), 2 deletions(-)

[PATCH 3/4] net: IP defrag: encapsulate rbtree defrag code into callable functions

Herbert Signed-off-by: David S. Miller (backported from commit c23f35d19db3b36ffb9e04b08f1d91565d15f84f) [smb: open code skb_mark_not_on_list(), context adjustments, use of IP_INC_STATS_BH instead of __IP_INC_STATS] Signed-off-by: Stefan Bader --- include/net/inet_frag.h | 16 ++- net/ipv4

[PATCH 4/4] ipv6: frags: Use inet_frag_pull_head() in ip6_expire_frag_queue()

[] __xfrm_decode_session+0x39/0x50 [] icmpv6_route_lookup+0xf0/0x1c0 [] icmp6_send+0x5e1/0x940 [] icmpv6_send+0x21/0x30 [] ip6_expire_frag_queue+0xe0/0x120 Signed-off-by: Stefan Bader --- net/ipv6/reassembly.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/net

[PATCH 2/4] ip: fail fast on IP defrag errors

ragments as overlapping"] Signed-off-by: Stefan Bader --- net/ipv4/ip_fragment.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c index 5387e6ab78d7..a53652c8c0fd 100644 --- a/net/ipv4/ip_fragm

Re: [PATCH AUTOSEL 5.1 011/375] ip6: fix skb leak in ip6frag_expire_frag_queue()

On 22.05.19 21:15, Sasha Levin wrote: > From: Eric Dumazet > > [ Upstream commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4 ] > > Since ip6frag_expire_frag_queue() now pulls the head skb > from frag queue, we should no longer use skb_get(), since > this leads to an skb le

Re: [PATCH 4.4 018/101] netfilter: synproxy: fix conntrackd interaction

On 03.07.2017 15:34, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. We found that pulling below patch into stable trees without also pulling commit 9c3f3794926a997b1cab6c42480ff300efa2d162 Author: Liping Zhang Date:

Re: [PATCH 4.4 018/101] netfilter: synproxy: fix conntrackd interaction

On 03.07.2017 15:34, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. We found that pulling below patch into stable trees without also pulling commit 9c3f3794926a997b1cab6c42480ff300efa2d162 Author: Liping Zhang Date: Sat Mar 25 16:35:29

[PATCH] bcache: Fix bcache device names

: partition support: add 16 minors per bcacheN device) Cc: <sta...@vger.kernel.org> # v4.10 Signed-off-by: Stefan Bader <stefan.ba...@canonical.com> --- drivers/md/bcache/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bc

[PATCH] bcache: Fix bcache device names

: partition support: add 16 minors per bcacheN device) Cc: # v4.10 Signed-off-by: Stefan Bader --- drivers/md/bcache/super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index 85e3f21..817e155 100644 --- a/drivers/md/bcache

Re: bcache super block corruption with non 4k pages

On 28.07.2016 18:27, Stefan Bader wrote: > On 28.07.2016 07:55, Kent Overstreet wrote: >> On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote: >>> So here is another attempt which does half the proposed changes. And before >>> you >>> point out that

Re: bcache super block corruption with non 4k pages

On 28.07.2016 18:27, Stefan Bader wrote: > On 28.07.2016 07:55, Kent Overstreet wrote: >> On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote: >>> So here is another attempt which does half the proposed changes. And before >>> you >>> point out that

Re: bcache super block corruption with non 4k pages

On 28.07.2016 07:55, Kent Overstreet wrote: > On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote: >> So here is another attempt which does half the proposed changes. And before >> you >> point out that it looks still ugly, let me explain some reasons. The goa

Re: bcache super block corruption with non 4k pages

On 28.07.2016 07:55, Kent Overstreet wrote: > On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote: >> So here is another attempt which does half the proposed changes. And before >> you >> point out that it looks still ugly, let me explain some reasons. The goa

Re: bcache super block corruption with non 4k pages

On 26.07.2016 14:49, Kent Overstreet wrote: > On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote: >> On 26.07.2016 12:21, Kent Overstreet wrote: >>> On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: >>>> On 21.07.2016 10:58, Stefan Ba

Re: bcache super block corruption with non 4k pages

On 26.07.2016 14:49, Kent Overstreet wrote: > On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote: >> On 26.07.2016 12:21, Kent Overstreet wrote: >>> On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: >>>> On 21.07.2016 10:58, Stefan Ba

Re: bcache super block corruption with non 4k pages

On 26.07.2016 12:21, Kent Overstreet wrote: > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: >> On 21.07.2016 10:58, Stefan Bader wrote: >>> I was pointed at the thread which seems to address the same after >>> I wrote most of below text. Did not want

Re: bcache super block corruption with non 4k pages

On 26.07.2016 12:21, Kent Overstreet wrote: > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: >> On 21.07.2016 10:58, Stefan Bader wrote: >>> I was pointed at the thread which seems to address the same after >>> I wrote most of below text. Did not want

Re: bcache super block corruption with non 4k pages

On 21.07.2016 10:58, Stefan Bader wrote: > I was pointed at the thread which seems to address the same after > I wrote most of below text. Did not want to re-write this so please > bear with the odd layout. > > https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html >

Re: bcache super block corruption with non 4k pages

On 21.07.2016 10:58, Stefan Bader wrote: > I was pointed at the thread which seems to address the same after > I wrote most of below text. Did not want to re-write this so please > bear with the odd layout. > > https://www.redhat.com/archives/dm-devel/2016-June/msg00015.html >

Re: mm: Use phys_addr_t for reserve_bootmem_region arguments

On 17.05.2016 15:20, Stefan Bader wrote: > Re-posting to a hopefully better suited audience. I hit this problem > when trying to boot a i386 dom0 (PAE enabled) on a 64bit Xen host using > a config which would result in a reserved memory range starting at 4MB. Of course that ^ should be

Re: mm: Use phys_addr_t for reserve_bootmem_region arguments

On 17.05.2016 15:20, Stefan Bader wrote: > Re-posting to a hopefully better suited audience. I hit this problem > when trying to boot a i386 dom0 (PAE enabled) on a 64bit Xen host using > a config which would result in a reserved memory range starting at 4MB. Of course that ^ should be

mm: Use phys_addr_t for reserve_bootmem_region arguments

as the type for start and end as that is the type used in the memblock region definitions and those are 64bit (at least with PAE enabled). -Stefan >From 1588a8b3983f63f8e690b91e99fe631902e38805 Mon Sep 17 00:00:00 2001 From: Stefan Bader <stefan.ba...@canonical.com> Date: Tue, 10 May 2

mm: Use phys_addr_t for reserve_bootmem_region arguments

as the type for start and end as that is the type used in the memblock region definitions and those are 64bit (at least with PAE enabled). -Stefan >From 1588a8b3983f63f8e690b91e99fe631902e38805 Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Tue, 10 May 2016 19:05:16 +0200 Subject: [PA

Re: [Xen-devel] bad page flags booting 32bit dom0 on 64bit hypervisor using dom0_mem (kernel >=4.2)

On 02.05.2016 16:24, Stefan Bader wrote: > On 02.05.2016 13:41, Juergen Gross wrote: >> On 02/05/16 12:47, Stefan Bader wrote: >>> I recently tried to boot 32bit dom0 on 64bit Xen host which I configured to >>> run >>> with a limited, fix amount of memo

Re: [Xen-devel] bad page flags booting 32bit dom0 on 64bit hypervisor using dom0_mem (kernel >=4.2)

On 02.05.2016 16:24, Stefan Bader wrote: > On 02.05.2016 13:41, Juergen Gross wrote: >> On 02/05/16 12:47, Stefan Bader wrote: >>> I recently tried to boot 32bit dom0 on 64bit Xen host which I configured to >>> run >>> with a limited, fix amount of memo

[PATCH resend] bcache: prevent crash on changing writeback_running

violation when writing 0 into writeback_running of a bcache device that is not attached to a cache set (without the patch). -Stefan --- >From e949c64fa6acbdaab999410250855a6a4fc6bad1 Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Mon, 18 Aug 2014 20:00:13 +0200 Subject: [PATCH] bcache: prev

[PATCH resend] bcache: prevent crash on changing writeback_running

violation when writing 0 into writeback_running of a bcache device that is not attached to a cache set (without the patch). -Stefan --- From e949c64fa6acbdaab999410250855a6a4fc6bad1 Mon Sep 17 00:00:00 2001 From: Stefan Bader stefan.ba...@canonical.com Date: Mon, 18 Aug 2014 20:00:13 +0200 Subject

Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.10

On 18.03.2015 10:18, Paolo Bonzini wrote: > > > On 18/03/2015 09:46, Stefan Bader wrote: >> >> Regardless of that, I wonder whether the below (this version untested) sound >> acceptable for upstream? At least it would make debugging much simpler. :) >> >>

Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 3.10

On 18.03.2015 10:18, Paolo Bonzini wrote: On 18/03/2015 09:46, Stefan Bader wrote: Regardless of that, I wonder whether the below (this version untested) sound acceptable for upstream? At least it would make debugging much simpler. :) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c

Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15

On 18.03.2015 11:27, Paolo Bonzini wrote: > > > On 18/03/2015 10:59, Stefan Bader wrote: >>> @@ -2850,7 +2851,7 @@ static __init int setup_vmcs_config(struct >>> vmcs_config *vmcs_conf) vmx_capability.ept, >>> vmx_capability.vpid); } >>> >>>

Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15

On 18.03.2015 10:18, Paolo Bonzini wrote: > > > On 18/03/2015 09:46, Stefan Bader wrote: >> >> Regardless of that, I wonder whether the below (this version untested) sound >> acceptable for upstream? At least it would make debugging much simpler. :) >> >>

regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15

Someone reported[1] that some of their L1 guests fail to load the kvm-intel module (without much details). Turns out that this was (at least) caused by KVM: vmx: Allow the guest to run with dirty debug registers as this adds VM_EXIT_SAVE_DEBUG_CONTROLS to the required MSR_IA32_VMX_EXIT_CTLS

Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 3.15

On 18.03.2015 11:27, Paolo Bonzini wrote: On 18/03/2015 10:59, Stefan Bader wrote: @@ -2850,7 +2851,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf) vmx_capability.ept, vmx_capability.vpid); } - min = 0; + min = VM_EXIT_SAVE_DEBUG_CONTROLS; #ifdef

Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 3.15

On 18.03.2015 10:18, Paolo Bonzini wrote: On 18/03/2015 09:46, Stefan Bader wrote: Regardless of that, I wonder whether the below (this version untested) sound acceptable for upstream? At least it would make debugging much simpler. :) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c

regression: nested: L1 3.15+ fails to load kvm-intel on L0 3.15

Someone reported[1] that some of their L1 guests fail to load the kvm-intel module (without much details). Turns out that this was (at least) caused by KVM: vmx: Allow the guest to run with dirty debug registers as this adds VM_EXIT_SAVE_DEBUG_CONTROLS to the required MSR_IA32_VMX_EXIT_CTLS

Re: [PATCH 3.18 129/151] x86/xen: Treat SCI interrupt as normal GSI interrupt

Cc: Len Brown > Cc: Pavel Machek > Cc: Bjorn Helgaas > Link: > http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang@linux.intel.com > Signed-off-by: Thomas Gleixner > Signed-off-by: Stefan Bader > Signed-off-by: Greg Kroah-Hartman > > --- > arch/

Re: [PATCH 3.18 129/151] x86/xen: Treat SCI interrupt as normal GSI interrupt

...@ucw.cz Cc: Bjorn Helgaas bhelg...@google.com Link: http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang@linux.intel.com Signed-off-by: Thomas Gleixner t...@linutronix.de Signed-off-by: Stefan Bader stefan.ba...@canonical.com Signed-off-by: Greg Kroah-Hartman gre

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

On 09.02.2015 20:15, Sander Eikelenboom wrote: > > Monday, February 9, 2015, 5:09:44 PM, you wrote: > >> On 09.02.2015 13:29, Stefan Bader wrote: >>> On 09.02.2015 13:12, Jiang Liu wrote: >>>> On 2015/2/9 17:47, Stefan Bader wrote: >>>>

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

On 09.02.2015 20:15, Sander Eikelenboom wrote: Monday, February 9, 2015, 5:09:44 PM, you wrote: On 09.02.2015 13:29, Stefan Bader wrote: On 09.02.2015 13:12, Jiang Liu wrote: On 2015/2/9 17:47, Stefan Bader wrote: On 05.02.2015 21:07, Sander Eikelenboom wrote: Tuesday, January 20, 2015

Re: 3.19: device name associates with IRQ's for ahci controllers operating with a single IRQ changed from "ahci?" to ""

On 09.02.2015 20:54, Sander Eikelenboom wrote: > Hi. > > In 3.19 the device name associates with IRQ's for ahci controllers operating > with a single IRQ changed from "ahci?" to "", was this intentional ? > > It's probably commit 18dcf433f3ded61eb140a55e7048ec2fef79e723 (or another one > in that

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

On 09.02.2015 13:29, Stefan Bader wrote: > On 09.02.2015 13:12, Jiang Liu wrote: >> On 2015/2/9 17:47, Stefan Bader wrote: >>> On 05.02.2015 21:07, Sander Eikelenboom wrote: >>>> >>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote: >>>>

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

On 09.02.2015 13:12, Jiang Liu wrote: > On 2015/2/9 17:47, Stefan Bader wrote: >> On 05.02.2015 21:07, Sander Eikelenboom wrote: >>> >>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote: >>> >>>> Hi Thomas, >>>> This patch set i

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

eed for xen_setup_acpi_sci() anymore. The above change also works with bare metal kernel too. Signed-off-by: Jiang Liu Tested-by: Sander Eikelenboom Cc: Tony Luck Cc: xen-de...@lists.xenproject.org Cc: Konrad Rzeszutek Wilk Cc: David Vrabel Cc: Rafael J. Wysocki Cc: Len Brown Cc: Pavel Machek C

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

Gleixner t...@linutronix.de Signed-off-by: Stefan Bader stefan.ba...@canonical.com --- arch/x86/kernel/acpi/boot.c | 23 +++--- arch/x86/pci/xen.c | 47 - 2 files changed, 12 insertions(+), 58 deletions(-) diff --git a/arch/x86

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

On 09.02.2015 13:29, Stefan Bader wrote: On 09.02.2015 13:12, Jiang Liu wrote: On 2015/2/9 17:47, Stefan Bader wrote: On 05.02.2015 21:07, Sander Eikelenboom wrote: Tuesday, January 20, 2015, 3:21:04 AM, you wrote: Hi Thomas, This patch set includes three hotfixes related Xen IRQ

Re: 3.19: device name associates with IRQ's for ahci controllers operating with a single IRQ changed from ahci? to BDF

On 09.02.2015 20:54, Sander Eikelenboom wrote: Hi. In 3.19 the device name associates with IRQ's for ahci controllers operating with a single IRQ changed from ahci? to BDF, was this intentional ? It's probably commit 18dcf433f3ded61eb140a55e7048ec2fef79e723 (or another one in that

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

On 09.02.2015 13:12, Jiang Liu wrote: On 2015/2/9 17:47, Stefan Bader wrote: On 05.02.2015 21:07, Sander Eikelenboom wrote: Tuesday, January 20, 2015, 3:21:04 AM, you wrote: Hi Thomas, This patch set includes three hotfixes related Xen IRQ for v3.19. Sorry for the long delay to get

Re: [PATCH] bcache: prevent crash on changing writeback_running

hen it would get pushed. -Stefan > > On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader > wrote: >> commit a664d0f05a2ec02c8f042db536d84d15d6e19e81 >> bcache: fix crash on shutdown in passthrough mode >> >> added a safeguard in the shutdown case. At least while not b

Re: [PATCH] bcache: prevent crash on changing writeback_running

get pushed. -Stefan On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader stefan.ba...@canonical.com wrote: commit a664d0f05a2ec02c8f042db536d84d15d6e19e81 bcache: fix crash on shutdown in passthrough mode added a safeguard in the shutdown case. At least while not being attached it is also

Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize

On 01.12.2014 14:59, Zoltan Kiss wrote: > > > On 01/12/14 13:36, David Vrabel wrote: >> On 01/12/14 08:55, Stefan Bader wrote: >>> On 11.08.2014 19:32, Zoltan Kiss wrote: >>>> There is a long known problem with the netfront/netback interface: if the >>

Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize

On 11.08.2014 19:32, Zoltan Kiss wrote: > There is a long known problem with the netfront/netback interface: if the > guest > tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring > slots, > it gets dropped. The reason is that netback maps these slots to a frag in the > frags

Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize

On 11.08.2014 19:32, Zoltan Kiss wrote: There is a long known problem with the netfront/netback interface: if the guest tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots, it gets dropped. The reason is that netback maps these slots to a frag in the frags array,

Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize

On 01.12.2014 14:59, Zoltan Kiss wrote: On 01/12/14 13:36, David Vrabel wrote: On 01/12/14 08:55, Stefan Bader wrote: On 11.08.2014 19:32, Zoltan Kiss wrote: There is a long known problem with the netfront/netback interface: if the guest tries to send a packet which constitues more than

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 07.11.2014 13:21, Zoltan Kiss wrote: > > > On 07/11/14 12:15, Stefan Bader wrote: >> On 07.11.2014 12:22, Eric Dumazet wrote: >>> On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote: >>> >>> Please do not top post. >>> >>>&

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 07.11.2014 12:22, Eric Dumazet wrote: > On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote: > > Please do not top post. > >> Hi, >> >> AFAIK in this scenario your skb frag is wrong. The page pointer should >> point to the original compound page (not a member of it), and offset >> should

Re: BUG in xennet_make_frags with paged skb data

On 07.11.2014 11:44, David Vrabel wrote: > On 06/11/14 21:49, Seth Forshee wrote: >> We've had several reports of hitting the following BUG_ON in >> xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting >> results of testing with 3.17): >> >> /* Grant backend access to each

Re: BUG in xennet_make_frags with paged skb data

On 07.11.2014 11:44, David Vrabel wrote: On 06/11/14 21:49, Seth Forshee wrote: We've had several reports of hitting the following BUG_ON in xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting results of testing with 3.17): /* Grant backend access to each skb fragment

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 07.11.2014 12:22, Eric Dumazet wrote: On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote: Please do not top post. Hi, AFAIK in this scenario your skb frag is wrong. The page pointer should point to the original compound page (not a member of it), and offset should be set

Re: [Xen-devel] BUG in xennet_make_frags with paged skb data

On 07.11.2014 13:21, Zoltan Kiss wrote: On 07/11/14 12:15, Stefan Bader wrote: On 07.11.2014 12:22, Eric Dumazet wrote: On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote: Please do not top post. Hi, AFAIK in this scenario your skb frag is wrong. The page pointer should point

Re: [Xen-devel] [PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests

On 02.09.2014 13:01, David Vrabel wrote: > On 01/09/14 18:34, David Vrabel wrote: >> On 29/08/14 16:17, Stefan Bader wrote: >>> >>> This change might not be the fully correct approach as it basically >>> removes the pre-set page table entry for the

Re: [Xen-devel] [PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests

On 02.09.2014 13:01, David Vrabel wrote: On 01/09/14 18:34, David Vrabel wrote: On 29/08/14 16:17, Stefan Bader wrote: This change might not be the fully correct approach as it basically removes the pre-set page table entry for the fixmap that is compile time set (level2_fixmap_pgt[506

[PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests

still, something does create entries at level2_fixmap_pgt[506..507]. So it should be ok. At least I was able to successfully boot a kernel with 1G kernel image size without any vmalloc whinings. Signed-off-by: Stefan Bader Cc: sta...@vger.kernel.org --- arch/x86/xen/mmu.c | 26 +-

Re: [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 16:31, David Vrabel wrote: > On 29/08/14 15:27, Stefan Bader wrote: >> >> Ok, I rework the patch and re-send it (freshly, iow not part of this thread). >> And while I am at it, I would add the stable tag. > > Can you use a different title? Perhaps: >

Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 16:19, Andrew Cooper wrote: > On 29/08/14 09:37, Stefan Bader wrote: >> On 29.08.2014 00:42, Andrew Cooper wrote: >>> On 28/08/2014 19:01, Stefan Bader wrote: >>>>>> So not much further... but then I think I know what I do next. Probably >>

Re: [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 16:08, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 28, 2014 at 08:01:43PM +0200, Stefan Bader wrote: >>>> So not much further... but then I think I know what I do next. Probably >>>> should >>>> have done before. I'll replace the WARN_ON in

Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 00:42, Andrew Cooper wrote: > On 28/08/2014 19:01, Stefan Bader wrote: >>>> So not much further... but then I think I know what I do next. Probably >>>> should >>>> have done before. I'll replace the WARN_ON in vmalloc that triggers by a &

Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 00:42, Andrew Cooper wrote: On 28/08/2014 19:01, Stefan Bader wrote: So not much further... but then I think I know what I do next. Probably should have done before. I'll replace the WARN_ON in vmalloc that triggers by a panic and at least get a crash dump of that situation

Re: [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 16:08, Konrad Rzeszutek Wilk wrote: On Thu, Aug 28, 2014 at 08:01:43PM +0200, Stefan Bader wrote: So not much further... but then I think I know what I do next. Probably should have done before. I'll replace the WARN_ON in vmalloc that triggers by a panic and at least get

Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 16:19, Andrew Cooper wrote: On 29/08/14 09:37, Stefan Bader wrote: On 29.08.2014 00:42, Andrew Cooper wrote: On 28/08/2014 19:01, Stefan Bader wrote: So not much further... but then I think I know what I do next. Probably should have done before. I'll replace the WARN_ON

Re: [PATCH] Solved the Xen PV/KASLR riddle

On 29.08.2014 16:31, David Vrabel wrote: On 29/08/14 15:27, Stefan Bader wrote: Ok, I rework the patch and re-send it (freshly, iow not part of this thread). And while I am at it, I would add the stable tag. Can you use a different title? Perhaps: x86/xen: fix 64-bit PV guest kernel page

[PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests

[506..507]. So it should be ok. At least I was able to successfully boot a kernel with 1G kernel image size without any vmalloc whinings. Signed-off-by: Stefan Bader stefan.ba...@canonical.com Cc: sta...@vger.kernel.org --- arch/x86/xen/mmu.c | 26 +- 1 file changed, 17

[PATCH] Solved the Xen PV/KASLR riddle

t)... I still need to compile a kernel with the patch and the old layout but I kind of got exited by the find. At least this is tested with the 1G/~1G layout and it comes up without vmalloc errors. -Stefan >From 4b9a9a45177284e29d345eb54c545bd1da718e1b Mon Sep 17 00:00:00 2001 From: Stefan Bad

[PATCH] Solved the Xen PV/KASLR riddle

layout but I kind of got exited by the find. At least this is tested with the 1G/~1G layout and it comes up without vmalloc errors. -Stefan From 4b9a9a45177284e29d345eb54c545bd1da718e1b Mon Sep 17 00:00:00 2001 From: Stefan Bader stefan.ba...@canonical.com Date: Thu, 28 Aug 2014 19:17:00 +0200

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 26.08.2014 18:01, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 22, 2014 at 11:20:50AM +0200, Stefan Bader wrote: >> On 21.08.2014 18:03, Kees Cook wrote: >>> On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk >>> wrote: >>>> On Tue, Aug 12, 20

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 26.08.2014 18:01, Konrad Rzeszutek Wilk wrote: On Fri, Aug 22, 2014 at 11:20:50AM +0200, Stefan Bader wrote: On 21.08.2014 18:03, Kees Cook wrote: On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Aug 12, 2014 at 11:53:03AM -0700, Kees Cook wrote

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 21.08.2014 18:03, Kees Cook wrote: > On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk > wrote: >> On Tue, Aug 12, 2014 at 11:53:03AM -0700, Kees Cook wrote: >>> On Tue, Aug 12, 2014 at 11:05 AM, Stefan Bader >>> wrote: >>>> On 12.08.2014 19:28,

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 21.08.2014 18:03, Kees Cook wrote: On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Aug 12, 2014 at 11:53:03AM -0700, Kees Cook wrote: On Tue, Aug 12, 2014 at 11:05 AM, Stefan Bader stefan.ba...@canonical.com wrote: On 12.08.2014 19:28, Kees

Re: [PATCH] bcache: prevent crash on changing writeback_running

gc... -Stefan > > On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader > wrote: >> commit a664d0f05a2ec02c8f042db536d84d15d6e19e81 >> bcache: fix crash on shutdown in passthrough mode >> >> added a safeguard in the shutdown case. At least while not being >> attach

Re: [PATCH] bcache: prevent crash on changing writeback_running

... -Stefan On Tue, Aug 19, 2014 at 6:01 AM, Stefan Bader stefan.ba...@canonical.com wrote: commit a664d0f05a2ec02c8f042db536d84d15d6e19e81 bcache: fix crash on shutdown in passthrough mode added a safeguard in the shutdown case. At least while not being attached it is also possible

[PATCH] bcache: prevent crash on changing writeback_running

trying to wake up the thread for that case. Signed-off-by: Stefan Bader --- drivers/md/bcache/writeback.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/bcache/writeback.h b/drivers/md/bcache/writeback.h index 0a9dab1..073a042 100644 --- a/drivers/md/bcache

[PATCH] bcache: prevent crash on changing writeback_running

trying to wake up the thread for that case. Signed-off-by: Stefan Bader stefan.ba...@canonical.com --- drivers/md/bcache/writeback.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/bcache/writeback.h b/drivers/md/bcache/writeback.h index 0a9dab1..073a042 100644

[tip:x86/urgent] x86_32, entry: Clean up sysenter_badsys declaration

Commit-ID: fb21b84e7f809ef04b1e5aed5d463cf0d4866638 Gitweb: http://git.kernel.org/tip/fb21b84e7f809ef04b1e5aed5d463cf0d4866638 Author: Stefan Bader AuthorDate: Fri, 15 Aug 2014 10:57:46 +0200 Committer: H. Peter Anvin CommitDate: Fri, 15 Aug 2014 13:45:32 -0700 x86_32, entry: Clean up

[PATCH] x86_32, entry: Clean up sysenter_badsys declaration

f symmetry, change the second syscall_badsys to sysenter_badsys. Signed-off-by: Stefan Bader --- arch/x86/kernel/entry_32.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 47c410d..4b0e1df 100644 --- a/arch/x86/kernel/

[PATCH] x86_32, entry: Clean up sysenter_badsys declaration

, change the second syscall_badsys to sysenter_badsys. Signed-off-by: Stefan Bader stefan.ba...@canonical.com --- arch/x86/kernel/entry_32.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 47c410d..4b0e1df 100644

[tip:x86/urgent] x86_32, entry: Clean up sysenter_badsys declaration

Commit-ID: fb21b84e7f809ef04b1e5aed5d463cf0d4866638 Gitweb: http://git.kernel.org/tip/fb21b84e7f809ef04b1e5aed5d463cf0d4866638 Author: Stefan Bader stefan.ba...@canonical.com AuthorDate: Fri, 15 Aug 2014 10:57:46 +0200 Committer: H. Peter Anvin h...@linux.intel.com CommitDate: Fri, 15

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 12.08.2014 19:28, Kees Cook wrote: > On Fri, Aug 8, 2014 at 7:35 AM, Stefan Bader > wrote: >> On 08.08.2014 14:43, David Vrabel wrote: >>> On 08/08/14 12:20, Stefan Bader wrote: >>>> Unfortunately I have not yet figured out why this happens, but ca

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 12.08.2014 19:28, Kees Cook wrote: On Fri, Aug 8, 2014 at 7:35 AM, Stefan Bader stefan.ba...@canonical.com wrote: On 08.08.2014 14:43, David Vrabel wrote: On 08/08/14 12:20, Stefan Bader wrote: Unfortunately I have not yet figured out why this happens, but can confirm by compiling

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 08.08.2014 14:43, David Vrabel wrote: > On 08/08/14 12:20, Stefan Bader wrote: >> Unfortunately I have not yet figured out why this happens, but can confirm by >> compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR >> all >> is ok, but with

Xen PV domain regression with KASLR enabled (kernel 3.16)

Unfortunately I have not yet figured out why this happens, but can confirm by compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR all is ok, but with it enabled there are issues (actually a dom0 does not even boot as a follow up error). Details can be seen in [1] but

Xen PV domain regression with KASLR enabled (kernel 3.16)

Unfortunately I have not yet figured out why this happens, but can confirm by compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR all is ok, but with it enabled there are issues (actually a dom0 does not even boot as a follow up error). Details can be seen in [1] but

Re: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)

On 08.08.2014 14:43, David Vrabel wrote: On 08/08/14 12:20, Stefan Bader wrote: Unfortunately I have not yet figured out why this happens, but can confirm by compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR all is ok, but with it enabled there are issues (actually

Re: fs/stat: Reduce memory requirements for stat_open

On 08.07.2014 15:09, Peter Zijlstra wrote: > On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote: >> When reading from /proc/stat we allocate a large buffer to maximise >> the chances of the results being from a single run and thus internally >> consistent. This curr

Re: fs/stat: Reduce memory requirements for stat_open

On 08.07.2014 15:09, Peter Zijlstra wrote: On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote: When reading from /proc/stat we allocate a large buffer to maximise the chances of the results being from a single run and thus internally consistent. This currently is sized at 128

  1   2   3   >