Folks,
I got this warning today. I cant tell when and why this happened, so I do not
know yet how to reproduce.
Maybe someone has a quick idea.
[85109.572032] WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764
__skb_flow_dissect+0x1f0/0x1318
[85109.572036] Modules linked in: vhost_ne
essful architecture initialization.
>>>
>>> A related indication of the issue will be reported as kernel
>>> message.
>>>
>>> Signed-off-by: Michael Mueller
>>> Reviewed-by: Cornelia Huck
>>> Reviewed-by: Pierre Morel
>>> Rev
On 20.12.2018 10:12, Ido Schimmel wrote:
> +Willem
>
> On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote:
>> Folks,
>>
>> I got this warning today. I cant tell when and why this happened, so I do
>> not know yet how to reproduce.
On 20.12.2018 18:23, Willem de Bruijn wrote:
> On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel wrote:
>>
>> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote:
>>> On 20.12.2018 10:12, Ido Schimmel wrote:
>>>> +Willem
>>>&g
w_dissector: lookup netns by skb->sk if skb->dev is
> NULL")
> Reported-by: Christian Borntraeger
> Signed-off-by: Willem de Bruijn
> Signed-off-by: David S. Miller
> Signed-off-by: Greg Kroah-Hartman
I can confirm that this fixes my issue.
Tested-by: Christian Bo
Can you please cc stable? Right now 4.20 does not work under KVM.
On 07.01.2019 08:01, Wei Wang wrote:
> Since virtio-ccw doesn't work with accessing to the config space
> inside an interrupt context, this patch series avoids that issue by
> moving the config register accesses to the related wor
On 07.01.2019 14:45, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 03:01:03PM +0800, Wei Wang wrote:
>> Since virtio-ccw doesn't work with accessing to the config space
>> inside an interrupt context, this patch series avoids that issue by
>> moving the config register accesses to the rela
p is used as a flag to the workqueue callbacks
> about the related config fields that need to be read.
>
> The cmd_id_received is also renamed to cmd_id_received_cache, and
> the value should be obtained via virtio_balloon_cmd_id_received.
>
> Reported-by: Christian Borntrae
On 08.01.2019 06:35, Wei Wang wrote:
> On 01/07/2019 09:49 PM, Christian Borntraeger wrote:
>>
>> On 07.01.2019 08:01, Wei Wang wrote:
>>> virtio-ccw has deadlock issues with reading the config space inside the
>>> interrupt context, so we tweak the virtball
Martin,
Right now you get a message
"BUG: non-zero pgtables_bytes on freeing mm: -16384"
for EVERY process that exits in 4.19.5 and later.
bisect points to
commit 4136161d676a93fc8df6bdb80d720c15522d6c24
Author: Martin Schwidefsky
Date: Mon Oct 15 11:09:16 2018 +0200
s390/mm: fix mis-ac
On 27.12.2018 10:13, Christian Borntraeger wrote:
> Martin,
>
> Right now you get a message
> "BUG: non-zero pgtables_bytes on freeing mm: -16384"
> for EVERY process that exits in 4.19.5 and later.
>
> bisect points to
> commit 4136161d676a93fc8df6bdb
This patch triggers random crashes in the guest kernel on s390 early during
boot.
No migration and no setting of the balloon is involved.
On 27.08.2018 03:32, Wei Wang wrote:
> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
> series enables the virtio-balloon driver to r
On 27.12.2018 12:31, Christian Borntraeger wrote:
> This patch triggers random crashes in the guest kernel on s390 early during
> boot.
> No migration and no setting of the balloon is involved.
>
Adding Conny and Halil,
As the QEMU provides no PAGE_HINT feature yet, this quick ha
On 27.08.2018 03:32, Wei Wang wrote:
> static int init_vqs(struct virtio_balloon *vb)
> {
> - struct virtqueue *vqs[3];
> - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request
> };
> - static const char * const names[] = { "inflate", "deflate", "stats" };
> - i
On 27.12.2018 12:59, Christian Borntraeger wrote:
> On 27.12.2018 12:31, Christian Borntraeger wrote:
>> This patch triggers random crashes in the guest kernel on s390 early during
>> boot.
>> No migration and no setting of the balloon is involved.
>>
>
> Ad
On 12/27/2018 10:01 PM, Sasha Levin wrote:
> On Thu, Dec 27, 2018 at 10:28:56AM +0100, Christian Borntraeger wrote:
>>
>>
>> On 27.12.2018 10:13, Christian Borntraeger wrote:
>>> Martin,
>>>
>>> Right now you get a message
>>> "BUG
On 28.12.2018 03:26, Wei Wang wrote:
> Some vqs don't need to be allocated when the related feature bits are
> disabled. Callers notice the vq allocation layer by setting the related
> names[i] to be NULL.
>
> This patch series fixes the find_vqs implementations to handle this case.
So the ran
On 28.12.2018 04:12, Wei Wang wrote:
> On 12/27/2018 08:03 PM, Christian Borntraeger wrote:
>> On 27.08.2018 03:32, Wei Wang wrote:
>>> static int init_vqs(struct virtio_balloon *vb)
>>> {
>>> - struct virtqueue *vqs[3];
>>> - vq_callbac
On 10/09/2018 11:54 AM, Filippo Sironi wrote:
> Start populating /sys/hypervisor with KVM entries when we're running on
> KVM. This is to replicate functionality that's available when we're
> running on Xen.
>
> Let's start with /sys/hypervisor/uuid, which users prefer over
> /sys/devices/virtu
On 10/05/2018 09:54 AM, David Hildenbrand wrote:
> On 05/10/2018 09:50, Cornelia Huck wrote:
>> On Fri, 5 Oct 2018 09:33:01 +0200
>> Pierre Morel wrote:
>>
>>> Define a tracing function to trace in the KVM trace buffer
>>> and trace the changes of the APCB masks.
>>
>> In general, trace events
Both applied.
(FWIW, this was based on an older version of the ap patch set, I had to fixup
the 2 patch)
On 10/05/2018 10:31 AM, Pierre Morel wrote:
> In the first patch we define kvm_arch_crypto_set_masks,
> a new function to centralize the setup the APCB masks
> inside the CRYCB SIE satelite an
On 10/27/2018 06:07 AM, Stephen Smith wrote:
> On Wednesday, October 24, 2018 10:20:05 PM MST Stephen Smith wrote:
>>
>> Whenever I run "shutdown -h now" or "reboot" I receive an immediate kernel
>> crash with a dump that has:
>>
>> "Code: Bad RIP value"
>
> I Canonical response noted the foll
Am 16.11.23 um 11:13 schrieb Ilya Leoshkevich:
It's also possible to get a free s390 machine at [1].
[1] https://linuxone.cloud.marist.edu/oss
I think the URL for registration is this one
https://linuxone.cloud.marist.edu/#/register?flag=VM
Christopherson
Cc: Michael Tokarev
Cc: Christian Borntraeger
Signed-off-by: Wanpeng Li
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Reviewed-by: Christian Borntraeger
---
include/linux/context_tracking.h | 9 -
1 file changed, 8 insertions(+), 1
accounting.
Suggested-by: Thomas Gleixner
Cc: Thomas Gleixner
Cc: Michael Tokarev
Cc: Christian Borntraeger
Signed-off-by: Wanpeng Li
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Reviewed-by: Christian Borntraeger
---
include/linux/context_tracking.h | 24
Am Freitag, 28. September 2007 schrieb Andy Whitcroft:
> > And this is not about any particular false positive. I dont mind an
> > "advanced mode" non-default opt-in option for the script, if someone is
> > interested in borderline or hard to judge warnings too, but these
> > default false posit
Am Montag, 20. August 2007 schrieb Laurent Vivier:
> Index: kvm/fs/proc/array.c
> ===
> --- kvm.orig/fs/proc/array.c2007-08-20 11:11:30.0 +0200
> +++ kvm/fs/proc/array.c 2007-08-20 13:04:03.0 +0200
Just a heads up,
Am Montag, 20. August 2007 schrieb Martin Schwidefsky:
> On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
> Ok, that would mean that sched_clock can just return the virtual cpu
> time and the two hooks starts and stops the idle periods as far as the
> scheduler is concerned. In this case we ca
Am Montag, 20. August 2007 schrieb Ingo Molnar:
> ok. Just to make it sure wrt. release-management: you said s390
> sched_clock() is currently at least as precise as stime/utime - so this
> would suggest that there is no regression over v2.6.22? Regardless of
On current git s390 has a sched_clo
Am Montag, 20. August 2007 schrieb Glauber de Oliveira Costa:
> Although I don't know KVM to a that deep level, I think it should be
> possible to keep the virtual cpus in different process (or threads),
> and take the accounting time from there. Perfectly possible to know
> the time we spent runni
Am Montag, 20. August 2007 schrieb Ingo Molnar:
> could you send that precise sched_clock() patch? It should be an order
> of magnitude simpler than the high-precision stime/utime tracking you
> already do, and it's needed for quality scheduling anyway.
I have a question about that. I just playe
Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> Wouldnt it be more consistent if a virtual box would not show any
> dependency on external load? (i.e. it would slow down all of its
> internal functionality transparently, without exposing it via /proc. The
> only way to observe that would be
Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> the 'invariant' i mentioned only covers scheduler behavior, not
> accounting behavior. Accounting is separate in theory, but coupled in
> practice now via sum_exec_runtime.
Forgot to answer about that: That means that the current design does no
Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> you mean to revert b27f03d4bd? I'd really like to see this fixed for
> real for s390 + CONFIG_VIRT_CPU_ACCOUNTING=y. (which seems to be the
> only case affected)
Not a complete revert, but an ifdef-workaround. I wrote this patch last week
and
> what do you think about the rq_clock() #ifdef i did in the previous mail
> plus you making sched_clock() virtual? That way you can keep
> scheduler_tick() driven by real-time, although that generally will cause
> artifacts with SMP load-balancing too. (that was true in the past too)
I just ha
Am Dienstag, 21. August 2007 schrieben Sie:
> could you try the patch below, does it work any better?
I looked again at the scheduler code and things are getting better when I run
the patch below on top of your patch and with our sched_clock prototype. I
guess there is a reason why you want rq->
Hello Ingo,
Thanks you for applying the accouting fix.
I looked into Jans sched_clock prototype, and
here is an update for sched_clock on s390. This patch applies on
current git, but should not go in before 2.6.23 as this change
is not trivial. The patch itself is independent from other patches
virtual sched_clock() for s390
From: Jan Glauber <[EMAIL PROTECTED]>
From: Christian Borntraeger <[EMAIL PROTECTED]>
This patch introduces a cpu time clock for s390 (only ticking if
the virtual cpu is running) and bases the s390 implementation of
sched_clock() on it. The patch i
Currently the scheduler does sanity checking on sched_clock and corrects
the values. Remove some of these checks to make steal time influence the
process time.
This patch is probably nothing for upstream but with this patch the
accouting for s390 seems to work regarding steal time, even without
C
Am 05.12.2014 um 01:07 schrieb Hector Marco:
> [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
>
> The issue appears on PIE linked executables when all memory areas of
> a process are randomized (randomize_va_space=2). In this case, the
> attack "offset2lib" de-randomizes a
Am 08.12.2014 um 12:26 schrieb Stephen Rothwell:
> Hi Christian,
>
> After merging the acess_once tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> arch/powerpc/mm/hugetlbpage.c: In function 'find_linux_pte_or_hugepte':
> arch/powerpc/mm/hugetlbpage.c:981:3: error: inva
Am 10.12.2014 um 09:20 schrieb Stephen Rothwell:
> Hi Christian,
>
> After merging the access_once tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> In file included from /scratch/sfr/next/include/uapi/linux/stddef.h:1:0,
> from /scratch/sfr/next/i
From: Alexander Yarygin
The mmio and ioport events are useful only on x86.
Signed-off-by: Alexander Yarygin
Signed-off-by: Christian Borntraeger
---
tools/perf/builtin-kvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin
o all accesses via
scalar types as suggested by Linus Torvalds. Accesses larger than
the machines word size cannot be guaranteed to be atomic. These
macros will use memcpy and emit a build warning.
Signed-off-by: Christian Borntraeger
---
include/linux/compiler.h
.
Signed-off-by: Christian Borntraeger
Acked-by: Paul E. McKenney
---
arch/x86/mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
index 207d9aef..d754782 100644
--- a/arch/x86/mm/gup.c
+++ b/arch/x86/mm/gup.c
@@ -15,7 +15,7
READ_ONCE.
Signed-off-by: Christian Borntraeger
Acked-by: Paul E. McKenney
---
arch/x86/include/asm/spinlock.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 9295016..12a69b4 100644
--- a/arch/x86
;__u?? to avoid header
inclusion fun and compile errors
3. Actually provide data_access_exceeds_word_size.
4. also move handle_pte_fault to a barrier as there is ppc44x which has
64bit ptes and 32bit word size. Some sanity check from a VM person
would be good.
Cc: linux...@kvack.org
Now that all non-scalar users of ACCESS_ONCE have been converted
to READ_ONCE or ASSIGN once, lets tighten ACCESS_ONCE to only
work on scalar types.
This variant was proposed by Alexei Starovoitov.
Signed-off-by: Christian Borntraeger
Reviewed-by: Paul E. McKenney
---
include/linux/compiler.h
READ_ONCE.
Signed-off-by: Christian Borntraeger
Acked-by: Paul E. McKenney
---
arch/arm64/include/asm/spinlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/spinlock.h
b/arch/arm64/include/asm/spinlock.h
index c45b7b1..cee1287 100644
--- a/arch
cking") replace
ACCESS_ONCE with barriers. Lets use READ_ONCE instead.
Signed-off-by: Christian Borntraeger
Acked-by: Paul E. McKenney
---
arch/s390/kvm/gaccess.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/s390/kvm/gaccess.c b/arch/s390/kvm/gacce
.
Signed-off-by: Christian Borntraeger
Acked-by: Paul E. McKenney
---
arch/mips/mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
index 06ce17c..8aa50e3 100644
--- a/arch/mips/mm/gup.c
+++ b/arch/mips/mm/gup.c
@@ -30,7 +30,7
READ_ONCE.
Signed-off-by: Christian Borntraeger
Acked-by: Paul E. McKenney
---
arch/arm/include/asm/spinlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index ac4bfae..0fa4184 100644
--- a/arch/arm
is in handle_pte_fault. On ppc44x the word size is
32 bit, but a pte is 64 bit. A barrier is ok as well.
Signed-off-by: Christian Borntraeger
Cc: linux...@kvack.org
Acked-by: Paul E. McKenney
---
mm/gup.c| 2 +-
mm/memory.c | 11 ++-
mm/rmap.c | 3 ++-
3 files changed, 13 inser
Am 03.12.2014 um 23:30 schrieb Christian Borntraeger:
> As discussed on LKML http://marc.info/?i=54611D86.4040306%40de.ibm.com
> ACCESS_ONCE might fail with specific compiler for non-scalar accesses.
>
> Here is a set of patches to tackle that problem.
>
> The first patch intro
Am 05.12.2014 um 03:12 schrieb George Spelvin:
>> +#define READ_ONCE(p) \
>> + typeof(p) __val; __read_once_size(&p, &__val, sizeof(__val)); __val; })
>> +
>> +#define ASSIGN_ONCE(val, p) \
>> +({ typeof(p) __val; __val = val; __assign_once_size(&p, &__val,
>> sizeof(__val)); __val; })
>
Am 05.12.2014 um 11:32 schrieb Stephen Rothwell:
> Hi Christian,
>
> After merging the access_once tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/compiler.h:189:0,
> from include/uapi/linux/stddef.h:1,
>
Am 07.12.2014 um 21:57 schrieb Christian Borntraeger:
> Am 05.12.2014 um 11:32 schrieb Stephen Rothwell:
>> Hi Christian,
>>
>> After merging the access_once tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> In file
Am 08.12.2014 um 12:26 schrieb Stephen Rothwell:
> Hi Christian,
>
> After merging the acess_once tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> arch/powerpc/mm/hugetlbpage.c: In function 'find_linux_pte_or_hugepte':
> arch/powerpc/mm/hugetlbpage.c:981:3: error: inva
Am 05.12.2014 um 12:18 schrieb David Hildenbrand:
> This patch adds the pagefault_count to the thread_info of all
> architectures. It will be used to count the pagefault_disable() levels
> on a per-thread basis.
>
> We are not reusing the preempt_count as this is per cpu on x86 and we want to
> de
Am 23.12.2014 um 07:34 schrieb Stephen Rothwell:
> Hi Linus,
>
> On Mon, 22 Dec 2014 20:12:22 -0800 Linus Torvalds
> wrote:
>>
>> On Mon, Dec 22, 2014 at 6:17 PM, Stephen Rothwell
>> wrote:
>>>
>>> I have been carrying this merge fix patch for some time. It should
>>> have gone into the merge
Feedback has shown that WRITE_ONCE(x, val) is easier to use than
ASSIGN_ONCE(val,x).
There are no in-tree users yet, so lets change it for 3.19.
Signed-off-by: Christian Borntraeger
Acked-by: Peter Zijlstra
Acked-by: Davidlohr Bueso
Acked-by: Paul E. McKenney
---
include/linux/compiler.h
CE(x, val) is better than ASSIGN_ONCE(val, x)
Lets change that for 3.19 as 3.19 has no user yet, but the first users
will hit linux-next soon.
----
Christian Borntraeger (1):
kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x,
READ_ONCE.
Signed-off-by: Christian Borntraeger
---
arch/powerpc/kvm/book3s_hv_rm_xics.c | 8
arch/powerpc/kvm/book3s_xics.c | 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_xics.c
b/arch/powerpc/kvm
Folks,
fyi, this is my current patch queue for the next merge window. It
does contain a patch that will disallow ACCESS_ONCE on non-scalar
types.
The tree is part of linux-next and can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git linux-next
Christian
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Fixup gup_pmd_range.
Signed-off-by: Christian
so
use __force on that cast.
Fixes: a91ed664749c ("kernel: tighten rules for ACCESS ONCE")
Signed-off-by: Christian Borntraeger
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 5e186bf..
Now that all non-scalar users of ACCESS_ONCE have been converted
to READ_ONCE or ASSIGN once, lets tighten ACCESS_ONCE to only
work on scalar types.
This variant was proposed by Alexei Starovoitov.
Signed-off-by: Christian Borntraeger
Reviewed-by: Paul E. McKenney
---
include/linux/compiler.h
.
Signed-off-by: Christian Borntraeger
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index edbc7a6..cb71016 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -554,7 +554,7 @@ static bool alloc_p2m
READ_ONCE.
Signed-off-by: Christian Borntraeger
---
arch/powerpc/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 5ff4e07..620d0ec 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch
.o] Error 1
Replace ACCESS_ONCE with READ_ONCE to fix the problem.
Fixes: a91ed664749c ("kernel: tighten rules for ACCESS ONCE")
Cc: Paul E. McKenney
Cc: Christian Borntraeger
Signed-off-by: Guenter Roeck
Reviewed-by: Paul E. McKenney
Signed-off-by: Christian Borntraeger
---
a
commit 78bff1c8684f ("x86/ticketlock: Fix spin_unlock_wait() livelock")
introduced another ACCESS_ONCE case in x86 spinlock.h.
Change that as well.
Signed-off-by: Christian Borntraeger
Cc: Oleg Nesterov
---
arch/x86/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+),
Am 15.01.2015 um 11:43 schrieb David Vrabel:
> On 15/01/15 08:58, Christian Borntraeger wrote:
>> ACCESS_ONCE does not work reliably on non-scalar types. For
>> example gcc 4.6 and 4.7 might remove the volatile tag for such
>> accesses during the SRA (scalar replacemen
Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
> On 01/15, Christian Borntraeger wrote:
>>
>> --- a/arch/x86/include/asm/spinlock.h
>> +++ b/arch/x86/include/asm/spinlock.h
>> @@ -186,7 +186,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t
>&g
Am 15.01.2015 um 21:01 schrieb Oleg Nesterov:
> On 01/15, Christian Borntraeger wrote:
>>
>> Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
>>> On 01/15, Christian Borntraeger wrote:
>>>>
>>>> --- a/arch/x86/include/asm/spinlock.h
>>>>
Am 07.01.2015 um 20:18 schrieb Guenter Roeck:
> On Wed, Jan 07, 2015 at 10:09:22AM -0800, Paul E. McKenney wrote:
>> On Wed, Jan 07, 2015 at 09:30:22AM -0800, Guenter Roeck wrote:
>>> On Wed, Jan 07, 2015 at 08:33:10AM -0800, Paul E. McKenney wrote:
On Wed, Jan 07, 2015 at 06:26:56AM -0800, Gu
Am 07.01.2015 um 22:04 schrieb Paul E. McKenney:
> On Wed, Jan 07, 2015 at 12:32:28PM -0800, Guenter Roeck wrote:
>> Commit a91ed664749c ("kernel: tighten rules for ACCESS ONCE") results in a
>> compile failure for sh builds with CONFIG_X2TLB enabled.
>>
>> arch/sh/mm/gup.c: In function 'gup_get_pt
Am 09.01.2015 um 14:56 schrieb Peter Zijlstra:
> On Fri, Jan 09, 2015 at 05:49:54AM -0800, Paul E. McKenney wrote:
>>> That reminds me, I think the new conversion for stores will most likely
>>> introduce silly arg bugs:
>>>
>>> - ACCESS_ONCE(a) = b;
>>> + ASSIGN_ONCE(b, a);
>>
>> I was
Am 12.01.2015 um 23:12 schrieb Paul E. McKenney:
> On Mon, Jan 12, 2015 at 09:59:57AM +0100, Peter Zijlstra wrote:
>> On Fri, Jan 09, 2015 at 10:58:50PM +0100, Christian Borntraeger wrote:
>>> Am 09.01.2015 um 14:56 schrieb Peter Zijlstra:
>>>> On Fri, Jan 09, 20
Am 16.01.2015 um 00:09 schrieb Michael Ellerman:
> On Thu, 2015-01-15 at 09:58 +0100, Christian Borntraeger wrote:
>> ACCESS_ONCE does not work reliably on non-scalar types. For
>> example gcc 4.6 and 4.7 might remove the volatile tag for such
>> accesses during the SRA (
i Kivity2006-12-10 2053
> switch (ioctl) {
> 9a2bb7f4 drivers/kvm/kvm_main.c Avi Kivity2007-02-22 2054
> case KVM_RUN:
> f0fe5108 drivers/kvm/kvm_main.c Avi Kivity 2007-03-07 2055
> r = -EINVAL;
> f0fe5108 drivers/kvm/kvm_main.c Avi Kivity
Am 30.03.2015 um 16:28 schrieb Michael Mueller:
> Signed-off-by: Michael Mueller
> ---
> linux-headers/asm-s390/kvm.h | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
Looks like a leftover. Drop that patch and rename ibc_range to ibc in the other
patch.
> diff --g
ch but not the other for whatever reasons.
this patch is then.
Reviewed-by: Christian Borntraeger
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/s390/kvm/virtio_ccw.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/s390/kv
Am 13.04.2015 um 15:56 schrieb Michael Mueller:
> This patch implements the QMP command 'query-cpu-definitions' in the S390
> context. The command returns a list of cpu definitions in the current host
> context. A runnable and migratable cpu model has the related attributes
> set to true. The order
Am 13.04.2015 um 15:56 schrieb Michael Mueller:
> --- a/target-s390x/cpu-models.c
> +++ b/target-s390x/cpu-models.c
> @@ -88,3 +88,85 @@ S390_PROC_DEF("2827-ga2", CPU_S390_2827_GA2, "IBM
> zEnterprise EC12 GA2")
[...]
> +int set_s390_cpu_alias(const char *name, const char *model)
> +{
> +S390C
e QMP
level I think this is almost good to go.
I have some minor style things as followup. With that fixed
Acked-by: Christian Borntraeger
for the series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
Am 13.04.2015 um 15:56 schrieb Michael Mueller:
> --- a/target-s390x/cpu-models.c
> +++ b/target-s390x/cpu-models.c
> @@ -76,3 +87,4 @@ S390_PROC_DEF("2827-ga1", CPU_S390_2827_GA1, "IBM
> zEnterprise EC12 GA1")
> S390_PROC_DEF("2827-ga2", CPU_S390_2827_GA2, "IBM zEnterprise EC12 GA2")
> S390_PR
Am 13.04.2015 um 15:56 schrieb Michael Mueller:
[...]
> +FAC_TRANSACTIONAL_EXE = 73,
> +/*
> + * The store-hypervisor-information facility #74 is
> + * z/VM related and when added to be handled by QEMU
> + * when hosted on LPAR. (see: SC24-6179-05 page 953)
> +
Am 13.04.2015 um 15:56 schrieb Michael Mueller:
[...]
> +static int cpu_model_get(KVMState *s, uint64_t attr, uint64_t addr)
> +{
> +int rc = -ENOSYS;
> +struct kvm_device_attr dev_attr = {
> +.group = KVM_S390_VM_CPU_MODEL,
> +.attr = attr,
> +.addr = addr,
Would i
Am 27.04.2015 um 10:55 schrieb Michael Mueller:
> On Mon, 27 Apr 2015 10:11:37 +0200
> Christian Borntraeger wrote:
>
>> Am 13.04.2015 um 15:56 schrieb Michael Mueller:
>> [...]
>>> +FAC_TRANSACTIONAL_EXE = 73,
>>> +/*
>>> +
Am 27.04.2015 um 11:43 schrieb Michael Mueller:
> On Mon, 27 Apr 2015 10:15:47 +0200
> Christian Borntraeger wrote:
>
>> Am 13.04.2015 um 15:56 schrieb Michael Mueller:
>> [...]
>>> +static int cpu_model_get(KVMState *s, uint64_t attr, uint64_t addr)
&g
Am 30.04.2015 um 13:57 schrieb Preeti U Murthy:
> Looks like commit :
>
> 43239cbe79fc ("kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)")
>
> left behind a reference to ASSIGN_ONCE. Update this to WRITE_ONCE.
>
> Signed-off-by: Preeti U Murthy
Am 30.04.2015 um 14:40 schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini
Reviewed-by: Christian Borntraeger
but no way to test it
> ---
> arch/powerpc/kvm/booke.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c
Am 09.04.2015 um 10:44 schrieb l...@kernel.org:
> From: Christian Borntraeger
>
> 3.4.107-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
>
> commit 2dca485f8740208604543c3960be31a5dd3ea603 upstream.
Hmmm, I just reali
Am 28.05.2015 um 13:52 schrieb Dominik Dingel:
> Hi everyone,
>
> there is a potential bug with KVM and hugetlbfs if the hardware does not
> support hugepages (EDAT1).
> We fix this by making EDAT1 a hard requirement for hugepages and
> therefore removing and simplifying code.
The cleanup itself
Am 18.06.2015 um 12:20 schrieb Michael S. Tsirkin:
> Needs more testing. Anyone see anything wrong with this?
Can you explain the motivation?
FWIW, basic networking between two guest over macvtap still
seems to work on s390 so I dont see any obvious regression.
Christian
>
> Signed-off-by: Mich
;
>>This is indicated by setting facilities bit 15 for
>>the guest. The kernel will not enable this facility for
>>the guest if it is not set on the host. This facility
>>must not be set by userspace if the KVM_S390_VM_CPU_FEAT_AP
>>feature is not i
ude/asm/kvm-ap.h
> create mode 100644 arch/s390/kvm/kvm-ap.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0ec5881..72742d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11875,6 +11875,16 @@ W:
> http://www.ibm.com/developerworks/linux/linux390/
> S:
On 04/05/2018 12:42 PM, Christian Borntraeger wrote:
>
>
> On 03/14/2018 07:25 PM, Tony Krowiak wrote:
>> This patch refactors the code that initializes the crypto
>> configuration for a guest. The crypto configuration is contained in
>> a crypto control block (
rchs, in the future this might be extended again if needed.
>
> Reviewed-by: Cornelia Huck
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Cornelia Huck
> Cc: Christian Borntraeger
> Signed-off-by: Wanpeng Li
> Signed-off-by: Tonny Lu
Acked-by: Christian Borntraeger
On 04/27/2018 03:58 PM, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Martin Schwidefsky
>
>
> From: Christian Borntraeger
>
> [ Upstream commit 35b3fde6203b932b2b1a5
201 - 300 of 1093 matches
Mail list logo