From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: paulmck@linux.vnet.ibm.com
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
virtualization@lists.linux-foundation.org,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
user-mode-linux-devel@lists.sourceforge.net,
linux-sh@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, xen-devel@lists.xenproject.org,
Ingo Molnar <mingo@elte.hu>,
linux-xtensa@linux-xtensa.org, james.hogan@imgtec.com,
Arnd Bergmann <arnd@arndb.de>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
adi-buildroot-devel@lists.sourceforge.net, ddaney.cavm@gmail.com,
Thomas Gleixner <tglx@linutronix.de>,
linux-metag@vger.kernel.orglinux-a
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 21:36:50 +0000 [thread overview]
Message-ID: <569814F2.50801@imgtec.com> (raw)
In-Reply-To: <20160114212913.GF3818@linux.vnet.ibm.com>
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
>
>> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>>>
>>> The WRC+addr+addr is OK because data dependencies are not required to be
>>> transitive, in other words, they are not required to flow from one CPU to
>>> another without the help of an explicit memory barrier.
>> I don't see any reliable way to fit WRC+addr+addr into "DATA
>> DEPENDENCY BARRIERS" section recommendation to have data dependency
>> barrier between read of a shared pointer/index and read the shared
>> data based on that pointer. If you have this two reads, it doesn't
>> matter the rest of scenario, you should put the dependency barrier
>> in code anyway. If you don't do it in WRC+addr+addr scenario then
>> after years it can be easily changed to different scenario which
>> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
>> fails.
> The trick is that lockless_dereference() contains an
> smp_read_barrier_depends():
>
> #define lockless_dereference(p) \
> ({ \
> typeof(p) _________p1 = READ_ONCE(p); \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_________p1); \
> })
>
> Or am I missing your point?
WRC+addr+addr has no any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: <paulmck@linux.vnet.ibm.com>
Cc: Will Deacon <will.deacon@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
<linux-kernel@vger.kernel.org>, "Arnd Bergmann" <arnd@arndb.de>,
<linux-arch@vger.kernel.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
<virtualization@lists.linux-foundation.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>, Joe Perches <joe@perches.com>,
David Miller <davem@davemloft.net>, <linux-ia64@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-s390@vger.kernel.org>,
<sparclinux@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-metag@vger.kernel.org>, <linux-mips@linux-mips.org>,
<x86@kernel.org>, <user-mode-linux-devel@lists.sourceforge.net>,
<adi-buildroot-devel@lists.sourceforge.net>,
<linux-sh@vger.kernel.org>, <linux-xtensa@linux-xtensa.org>,
<xen-devel@lists.xenproject.org>,
"Ralf Baechle" <ralf@linux-mips.org>,
Ingo Molnar <mingo@kernel.org>, <ddaney.cavm@gmail.com>,
<james.hogan@imgtec.com>, Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 13:36:50 -0800 [thread overview]
Message-ID: <569814F2.50801@imgtec.com> (raw)
In-Reply-To: <20160114212913.GF3818@linux.vnet.ibm.com>
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
>
>> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>>>
>>> The WRC+addr+addr is OK because data dependencies are not required to be
>>> transitive, in other words, they are not required to flow from one CPU to
>>> another without the help of an explicit memory barrier.
>> I don't see any reliable way to fit WRC+addr+addr into "DATA
>> DEPENDENCY BARRIERS" section recommendation to have data dependency
>> barrier between read of a shared pointer/index and read the shared
>> data based on that pointer. If you have this two reads, it doesn't
>> matter the rest of scenario, you should put the dependency barrier
>> in code anyway. If you don't do it in WRC+addr+addr scenario then
>> after years it can be easily changed to different scenario which
>> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
>> fails.
> The trick is that lockless_dereference() contains an
> smp_read_barrier_depends():
>
> #define lockless_dereference(p) \
> ({ \
> typeof(p) _________p1 = READ_ONCE(p); \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_________p1); \
> })
>
> Or am I missing your point?
WRC+addr+addr has no any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: paulmck@linux.vnet.ibm.com
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
virtualization@lists.linux-foundation.org,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
user-mode-linux-devel@lists.sourceforge.net,
linux-sh@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, xen-devel@lists.xenproject.org,
Ingo Molnar <mingo@elte.hu>,
linux-xtensa@linux-xtensa.org, james.hogan@imgtec.com,
Arnd Bergmann <arnd@arndb.de>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
adi-buildroot-devel@lists.sourceforge.net, ddaney.cavm@gmail.com,
Thomas Gleixner <tglx@linutronix.de>,
linux-metag@vger.kernel.orglinux-a
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 13:36:50 -0800 [thread overview]
Message-ID: <569814F2.50801@imgtec.com> (raw)
In-Reply-To: <20160114212913.GF3818@linux.vnet.ibm.com>
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
>
>> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>>>
>>> The WRC+addr+addr is OK because data dependencies are not required to be
>>> transitive, in other words, they are not required to flow from one CPU to
>>> another without the help of an explicit memory barrier.
>> I don't see any reliable way to fit WRC+addr+addr into "DATA
>> DEPENDENCY BARRIERS" section recommendation to have data dependency
>> barrier between read of a shared pointer/index and read the shared
>> data based on that pointer. If you have this two reads, it doesn't
>> matter the rest of scenario, you should put the dependency barrier
>> in code anyway. If you don't do it in WRC+addr+addr scenario then
>> after years it can be easily changed to different scenario which
>> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
>> fails.
> The trick is that lockless_dereference() contains an
> smp_read_barrier_depends():
>
> #define lockless_dereference(p) \
> ({ \
> typeof(p) _________p1 = READ_ONCE(p); \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_________p1); \
> })
>
> Or am I missing your point?
WRC+addr+addr has no any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: paulmck@linux.vnet.ibm.com
Cc: Will Deacon <will.deacon@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
linux-arch@vger.kernel.org,
Andrew Cooper <andrew.cooper3@citrix.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
virtualization@lists.linux-foundation.org,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>, Joe Perches <joe@perches.com>,
David Miller <davem@davemloft.net>,
linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, sparclinux@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
x86@kernel.org, user-mode-linux-devel@lists.sourceforge.net,
adi-buildroot-devel@lists.sourceforge.net,
linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org,
xen-devel@lists.xenproject.org,
Ralf Baechle <ralf@linux-mips.org>,
Ingo Molnar <mingo@kernel.org>,
ddaney.cavm@gmail.com, james.hogan@imgtec.com,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 13:36:50 -0800 [thread overview]
Message-ID: <569814F2.50801@imgtec.com> (raw)
Message-ID: <20160114213650.dA5oWAnE4Jdf5h_Bfc78IoXSEwhHIBKnf3vT3JE2Tao@z> (raw)
In-Reply-To: <20160114212913.GF3818@linux.vnet.ibm.com>
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
>
>> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>>>
>>> The WRC+addr+addr is OK because data dependencies are not required to be
>>> transitive, in other words, they are not required to flow from one CPU to
>>> another without the help of an explicit memory barrier.
>> I don't see any reliable way to fit WRC+addr+addr into "DATA
>> DEPENDENCY BARRIERS" section recommendation to have data dependency
>> barrier between read of a shared pointer/index and read the shared
>> data based on that pointer. If you have this two reads, it doesn't
>> matter the rest of scenario, you should put the dependency barrier
>> in code anyway. If you don't do it in WRC+addr+addr scenario then
>> after years it can be easily changed to different scenario which
>> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
>> fails.
> The trick is that lockless_dereference() contains an
> smp_read_barrier_depends():
>
> #define lockless_dereference(p) \
> ({ \
> typeof(p) _________p1 = READ_ONCE(p); \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_________p1); \
> })
>
> Or am I missing your point?
WRC+addr+addr has no any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid.Yegoshin@imgtec.com (Leonid Yegoshin)
To: linux-arm-kernel@lists.infradead.org
Subject: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 13:36:50 -0800 [thread overview]
Message-ID: <569814F2.50801@imgtec.com> (raw)
In-Reply-To: <20160114212913.GF3818@linux.vnet.ibm.com>
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
>
>> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>>>
>>> The WRC+addr+addr is OK because data dependencies are not required to be
>>> transitive, in other words, they are not required to flow from one CPU to
>>> another without the help of an explicit memory barrier.
>> I don't see any reliable way to fit WRC+addr+addr into "DATA
>> DEPENDENCY BARRIERS" section recommendation to have data dependency
>> barrier between read of a shared pointer/index and read the shared
>> data based on that pointer. If you have this two reads, it doesn't
>> matter the rest of scenario, you should put the dependency barrier
>> in code anyway. If you don't do it in WRC+addr+addr scenario then
>> after years it can be easily changed to different scenario which
>> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
>> fails.
> The trick is that lockless_dereference() contains an
> smp_read_barrier_depends():
>
> #define lockless_dereference(p) \
> ({ \
> typeof(p) _________p1 = READ_ONCE(p); \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_________p1); \
> })
>
> Or am I missing your point?
WRC+addr+addr has no any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: paulmck@linux.vnet.ibm.com
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
virtualization@lists.linux-foundation.org,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
user-mode-linux-devel@lists.sourceforge.net,
linux-sh@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, xen-devel@lists.xenproject.org,
Ingo Molnar <mingo@elte.hu>,
linux-xtensa@linux-xtensa.org, james.hogan@imgtec.com,
Arnd Bergmann <arnd@arndb.de>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
adi-buildroot-devel@lists.sourceforge.net, ddaney.cavm@gmail.com,
Thomas Gleixner <tglx@linutronix.de>,
linux-metag@vger.kernel.org, linux-a
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 13:36:50 -0800 [thread overview]
Message-ID: <569814F2.50801@imgtec.com> (raw)
In-Reply-To: <20160114212913.GF3818@linux.vnet.ibm.com>
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
>
>> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
>>>
>>> The WRC+addr+addr is OK because data dependencies are not required to be
>>> transitive, in other words, they are not required to flow from one CPU to
>>> another without the help of an explicit memory barrier.
>> I don't see any reliable way to fit WRC+addr+addr into "DATA
>> DEPENDENCY BARRIERS" section recommendation to have data dependency
>> barrier between read of a shared pointer/index and read the shared
>> data based on that pointer. If you have this two reads, it doesn't
>> matter the rest of scenario, you should put the dependency barrier
>> in code anyway. If you don't do it in WRC+addr+addr scenario then
>> after years it can be easily changed to different scenario which
>> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
>> fails.
> The trick is that lockless_dereference() contains an
> smp_read_barrier_depends():
>
> #define lockless_dereference(p) \
> ({ \
> typeof(p) _________p1 = READ_ONCE(p); \
> smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> (_________p1); \
> })
>
> Or am I missing your point?
WRC+addr+addr has no any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
next prev parent reply other threads:[~2016-01-14 21:36 UTC|newest]
Thread overview: 934+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-10 14:16 [PATCH v3 00/41] arch: barrier cleanup + barriers for virt Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-12 16:28 ` Paul E. McKenney
2016-01-12 16:28 ` Paul E. McKenney
2016-01-12 16:28 ` Paul E. McKenney
2016-01-12 16:28 ` Paul E. McKenney
2016-01-12 16:28 ` Paul E. McKenney
2016-01-12 16:28 ` Paul E. McKenney
2016-01-12 18:40 ` Michael S. Tsirkin
2016-01-12 18:40 ` Michael S. Tsirkin
2016-01-12 18:40 ` Michael S. Tsirkin
2016-01-12 18:40 ` Michael S. Tsirkin
2016-01-12 18:40 ` Michael S. Tsirkin
2016-01-12 18:40 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` [PATCH v3 02/41] asm-generic: guard smp_store_release/load_acquire Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` [PATCH v3 03/41] ia64: rename nop->iosapic_nop Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:16 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 04/41] ia64: reuse asm-generic/barrier.h Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
[not found] ` <1452426622-4471-1-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-01-10 14:17 ` [PATCH v3 05/41] powerpc: " Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-12 16:31 ` Paul E. McKenney
2016-01-12 16:31 ` Paul E. McKenney
2016-01-12 16:31 ` Paul E. McKenney
2016-01-12 16:31 ` Paul E. McKenney
2016-01-12 16:31 ` Paul E. McKenney
2016-01-12 16:31 ` Paul E. McKenney
2016-01-10 14:20 ` [PATCH v3 25/41] tile: define __smp_xxx Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 05/41] powerpc: reuse asm-generic/barrier.h Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 06/41] s390: " Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 07/41] sparc: " Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 08/41] arm: " Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 09/41] arm64: " Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` [PATCH v3 10/41] metag: " Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:17 ` Michael S. Tsirkin
2016-01-10 14:18 ` [PATCH v3 11/41] mips: " Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-12 1:14 ` [v3,11/41] " Leonid Yegoshin
2016-01-12 1:14 ` Leonid Yegoshin
2016-01-12 1:14 ` Leonid Yegoshin
2016-01-12 1:14 ` Leonid Yegoshin
2016-01-12 1:14 ` Leonid Yegoshin
2016-01-12 8:43 ` Michael S. Tsirkin
[not found] ` <56945366.2090504-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2016-01-12 8:43 ` Michael S. Tsirkin
2016-01-12 8:43 ` Michael S. Tsirkin
2016-01-12 8:43 ` Michael S. Tsirkin
2016-01-12 8:43 ` Michael S. Tsirkin
2016-01-12 9:51 ` Peter Zijlstra
2016-01-12 9:51 ` Peter Zijlstra
2016-01-12 9:51 ` Peter Zijlstra
2016-01-12 9:51 ` Peter Zijlstra
2016-01-12 9:51 ` Peter Zijlstra
2016-01-12 9:51 ` Peter Zijlstra
2016-01-12 8:43 ` Michael S. Tsirkin
2016-01-12 9:27 ` Peter Zijlstra
2016-01-12 9:27 ` Peter Zijlstra
2016-01-12 9:27 ` Peter Zijlstra
2016-01-12 9:27 ` Peter Zijlstra
2016-01-12 10:25 ` Peter Zijlstra
2016-01-12 10:25 ` Peter Zijlstra
2016-01-12 10:25 ` Peter Zijlstra
2016-01-12 10:25 ` Peter Zijlstra
2016-01-12 10:40 ` Peter Zijlstra
2016-01-12 10:40 ` Peter Zijlstra
2016-01-12 10:40 ` Peter Zijlstra
2016-01-12 10:40 ` Peter Zijlstra
2016-01-12 10:40 ` Peter Zijlstra
2016-01-12 11:41 ` Will Deacon
2016-01-12 11:41 ` Will Deacon
2016-01-12 11:41 ` Will Deacon
2016-01-12 11:41 ` Will Deacon
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 21:40 ` Peter Zijlstra
2016-01-12 21:40 ` Peter Zijlstra
2016-01-12 21:40 ` Peter Zijlstra
2016-01-12 21:40 ` Peter Zijlstra
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-13 0:21 ` Leonid Yegoshin
2016-01-12 21:40 ` Peter Zijlstra
2016-01-12 21:40 ` Peter Zijlstra
2016-01-13 10:45 ` Will Deacon
2016-01-13 10:45 ` Will Deacon
2016-01-13 10:45 ` Will Deacon
2016-01-13 10:45 ` Will Deacon
2016-01-13 10:45 ` Will Deacon
2016-01-13 10:45 ` Will Deacon
2016-01-13 10:45 ` Will Deacon
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 20:48 ` Peter Zijlstra
2016-01-13 20:48 ` Peter Zijlstra
2016-01-13 20:48 ` Peter Zijlstra
2016-01-13 20:48 ` Peter Zijlstra
2016-01-13 20:48 ` Peter Zijlstra
2016-01-13 20:48 ` Peter Zijlstra
2016-01-13 20:58 ` Leonid Yegoshin
2016-01-13 20:58 ` Leonid Yegoshin
2016-01-13 20:58 ` Leonid Yegoshin
2016-01-13 20:58 ` Leonid Yegoshin
2016-01-13 20:58 ` Leonid Yegoshin
2016-01-13 20:58 ` Leonid Yegoshin
[not found] ` <5696BA6E.4070508-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2016-01-14 12:04 ` Will Deacon
2016-01-14 12:04 ` Will Deacon
2016-01-14 12:04 ` Will Deacon
2016-01-14 12:04 ` Will Deacon
2016-01-14 12:04 ` Will Deacon
2016-01-14 16:16 ` Paul E. McKenney
2016-01-14 16:16 ` Paul E. McKenney
2016-01-14 16:16 ` Paul E. McKenney
2016-01-14 16:16 ` Paul E. McKenney
2016-01-14 16:16 ` Paul E. McKenney
2016-01-14 19:42 ` Leonid Yegoshin
2016-01-14 19:42 ` Leonid Yegoshin
2016-01-14 19:42 ` Leonid Yegoshin
2016-01-14 19:42 ` Leonid Yegoshin
2016-01-14 19:42 ` Leonid Yegoshin
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:15 ` Peter Zijlstra
2016-01-14 20:36 ` Paul E. McKenney
2016-01-14 20:36 ` Paul E. McKenney
2016-01-14 20:36 ` Paul E. McKenney
2016-01-14 20:36 ` Paul E. McKenney
2016-01-14 20:36 ` Paul E. McKenney
2016-01-14 20:46 ` Peter Zijlstra
2016-01-14 20:46 ` Peter Zijlstra
2016-01-14 20:46 ` Peter Zijlstra
2016-01-14 20:46 ` Peter Zijlstra
2016-01-14 20:46 ` Peter Zijlstra
2016-01-14 20:46 ` Peter Zijlstra
2016-01-14 20:46 ` Leonid Yegoshin
2016-01-14 20:46 ` Leonid Yegoshin
2016-01-14 20:46 ` Leonid Yegoshin
2016-01-14 20:46 ` Leonid Yegoshin
2016-01-14 20:46 ` Leonid Yegoshin
2016-01-14 20:46 ` Leonid Yegoshin
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:34 ` Paul E. McKenney
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 22:24 ` Paul E. McKenney
2016-01-14 22:24 ` Paul E. McKenney
2016-01-14 22:24 ` Paul E. McKenney
2016-01-14 22:24 ` Paul E. McKenney
2016-01-14 22:24 ` Paul E. McKenney
2016-01-14 22:24 ` Paul E. McKenney
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 23:04 ` Leonid Yegoshin
2016-01-14 21:45 ` Leonid Yegoshin
2016-01-14 19:42 ` Leonid Yegoshin
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 20:48 ` Paul E. McKenney
2016-01-14 20:48 ` Paul E. McKenney
2016-01-14 20:48 ` Paul E. McKenney
2016-01-14 20:48 ` Paul E. McKenney
2016-01-14 20:48 ` Paul E. McKenney
2016-01-14 20:48 ` Paul E. McKenney
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-14 22:20 ` Paul E. McKenney
2016-01-14 22:20 ` Paul E. McKenney
2016-01-14 22:20 ` Paul E. McKenney
2016-01-14 22:20 ` Paul E. McKenney
2016-01-14 22:20 ` Paul E. McKenney
2016-01-14 22:20 ` Paul E. McKenney
2016-01-15 9:57 ` Will Deacon
2016-01-15 9:57 ` Will Deacon
2016-01-15 9:57 ` Will Deacon
2016-01-15 9:57 ` Will Deacon
2016-01-15 9:57 ` Will Deacon
2016-01-15 18:54 ` Leonid Yegoshin
2016-01-15 18:54 ` Leonid Yegoshin
2016-01-15 18:54 ` Leonid Yegoshin
2016-01-15 18:54 ` Leonid Yegoshin
2016-01-15 18:54 ` Leonid Yegoshin
2016-01-15 18:54 ` Leonid Yegoshin
2016-01-26 10:24 ` Peter Zijlstra
2016-01-26 10:24 ` Peter Zijlstra
2016-01-26 10:24 ` Peter Zijlstra
2016-01-26 10:24 ` Peter Zijlstra
2016-01-26 10:32 ` Peter Zijlstra
2016-01-26 10:32 ` Peter Zijlstra
2016-01-26 10:32 ` Peter Zijlstra
2016-01-26 10:32 ` Peter Zijlstra
2016-01-26 10:32 ` Peter Zijlstra
2016-01-26 11:09 ` Will Deacon
[not found] ` <20160126103200.GI6375-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2016-01-26 11:09 ` Will Deacon
2016-01-26 11:09 ` Will Deacon
2016-01-26 11:09 ` Will Deacon
2016-01-26 11:09 ` Will Deacon
2016-01-26 20:11 ` Paul E. McKenney
2016-01-26 20:11 ` Paul E. McKenney
2016-01-26 20:11 ` Paul E. McKenney
2016-01-26 20:11 ` Paul E. McKenney
2016-01-26 20:11 ` Paul E. McKenney
2016-01-27 8:35 ` [PATCH] documentation: Add disclaimer Peter Zijlstra
2016-01-27 8:35 ` Peter Zijlstra
2016-01-27 8:35 ` Peter Zijlstra
2016-01-27 8:35 ` Peter Zijlstra
2016-01-27 8:35 ` Peter Zijlstra
2016-01-27 8:35 ` Peter Zijlstra
2016-01-27 10:11 ` Will Deacon
2016-01-27 10:11 ` Will Deacon
2016-01-27 10:11 ` Will Deacon
2016-01-27 10:11 ` Will Deacon
2016-01-27 10:11 ` Will Deacon
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-01-27 8:35 ` Peter Zijlstra
2016-01-27 14:57 ` David Howells
2016-01-27 14:57 ` David Howells
2016-01-27 14:57 ` David Howells
2016-01-27 14:57 ` David Howells
2016-01-27 14:57 ` David Howells
2016-01-27 14:57 ` David Howells
2016-01-27 23:35 ` Paul E. McKenney
2016-01-27 23:35 ` Paul E. McKenney
2016-01-27 23:35 ` Paul E. McKenney
2016-01-27 23:35 ` Paul E. McKenney
2016-01-27 23:35 ` Paul E. McKenney
2016-01-28 20:02 ` David Howells
2016-01-28 20:02 ` David Howells
2016-01-28 20:02 ` David Howells
2016-01-28 20:02 ` David Howells
2016-01-28 20:02 ` David Howells
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
[not found] ` <15882.1453906627-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-04-14 21:40 ` Paul E. McKenney
2016-01-27 14:57 ` David Howells
2016-01-26 11:09 ` [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon
2016-01-26 19:44 ` Paul E. McKenney
2016-01-26 19:44 ` Paul E. McKenney
2016-01-26 19:44 ` Paul E. McKenney
2016-01-26 19:44 ` Paul E. McKenney
2016-01-26 19:44 ` Paul E. McKenney
2016-01-26 19:44 ` Paul E. McKenney
2016-01-26 10:24 ` Peter Zijlstra
2016-01-14 22:20 ` Paul E. McKenney
2016-01-14 21:24 ` Leonid Yegoshin
2016-01-18 8:19 ` Herbert Xu
2016-01-18 8:19 ` Herbert Xu
2016-01-18 8:19 ` Herbert Xu
2016-01-18 8:19 ` Herbert Xu
2016-01-18 8:19 ` Herbert Xu
2016-01-18 8:19 ` Herbert Xu
2016-01-18 15:46 ` Paul E. McKenney
2016-01-18 15:46 ` Paul E. McKenney
2016-01-18 15:46 ` Paul E. McKenney
2016-01-18 15:46 ` Paul E. McKenney
2016-01-18 15:46 ` Paul E. McKenney
2016-01-26 16:52 ` Boqun Feng
2016-01-26 16:52 ` Boqun Feng
2016-01-26 16:52 ` Boqun Feng
2016-01-26 16:52 ` Boqun Feng
2016-01-26 16:52 ` Boqun Feng
2016-01-26 17:22 ` Peter Zijlstra
2016-01-26 17:22 ` Peter Zijlstra
2016-01-26 17:22 ` Peter Zijlstra
2016-01-26 17:22 ` Peter Zijlstra
2016-01-26 17:22 ` Peter Zijlstra
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:15 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 23:29 ` Paul E. McKenney
2016-01-26 23:29 ` Paul E. McKenney
2016-01-26 23:29 ` Paul E. McKenney
2016-01-26 23:29 ` Paul E. McKenney
2016-01-26 23:29 ` Paul E. McKenney
2016-01-26 23:45 ` Linus Torvalds
2016-01-26 23:45 ` Linus Torvalds
2016-01-26 23:45 ` Linus Torvalds
2016-01-26 23:45 ` Linus Torvalds
2016-01-26 23:45 ` Linus Torvalds
2016-01-26 23:45 ` Linus Torvalds
2016-01-27 0:57 ` Paul E. McKenney
2016-01-27 0:57 ` Paul E. McKenney
2016-01-27 0:57 ` Paul E. McKenney
2016-01-27 0:57 ` Paul E. McKenney
2016-01-27 0:57 ` Paul E. McKenney
2016-01-27 0:57 ` Paul E. McKenney
2016-01-26 23:45 ` Linus Torvalds
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 2:04 ` Boqun Feng
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 23:30 ` Paul E. McKenney
2016-01-27 2:04 ` Boqun Feng
2016-01-26 23:29 ` Paul E. McKenney
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 7:51 ` Peter Zijlstra
2016-01-27 8:05 ` Linus Torvalds
2016-01-27 8:05 ` Linus Torvalds
2016-01-27 8:05 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 22:33 ` Linus Torvalds
2016-01-26 20:10 ` Paul E. McKenney
2016-01-26 19:44 ` Linus Torvalds
2016-01-26 19:51 ` Paul E. McKenney
2016-01-26 19:51 ` Paul E. McKenney
2016-01-26 19:51 ` Paul E. McKenney
2016-01-26 19:51 ` Paul E. McKenney
2016-01-26 19:51 ` Paul E. McKenney
2016-01-26 16:52 ` Boqun Feng
2016-01-14 20:12 ` Leonid Yegoshin
2016-01-14 12:04 ` Will Deacon
2016-01-14 12:04 ` Will Deacon
2016-01-13 20:58 ` Leonid Yegoshin
2016-01-13 19:02 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-13 22:26 ` Leonid Yegoshin
2016-01-14 9:24 ` Michael S. Tsirkin
2016-01-14 9:24 ` Michael S. Tsirkin
2016-01-14 9:24 ` Michael S. Tsirkin
2016-01-14 9:24 ` Michael S. Tsirkin
2016-01-14 9:24 ` Michael S. Tsirkin
2016-01-14 9:24 ` Michael S. Tsirkin
2016-01-14 12:14 ` Will Deacon
2016-01-14 12:14 ` Will Deacon
[not found] ` <5696CF08.8080700-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2016-01-14 12:14 ` Will Deacon
2016-01-14 12:14 ` Will Deacon
2016-01-14 12:14 ` Will Deacon
2016-01-14 12:14 ` Will Deacon
2016-01-14 12:14 ` Will Deacon
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-14 20:34 ` Paul E. McKenney
2016-01-14 20:34 ` Paul E. McKenney
2016-01-14 20:34 ` Paul E. McKenney
2016-01-14 20:34 ` Paul E. McKenney
2016-01-14 20:34 ` Paul E. McKenney
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:01 ` Leonid Yegoshin
2016-01-14 21:29 ` Paul E. McKenney
2016-01-14 21:29 ` Paul E. McKenney
2016-01-14 21:29 ` Paul E. McKenney
2016-01-14 21:29 ` Paul E. McKenney
2016-01-14 21:29 ` Paul E. McKenney
2016-01-14 21:36 ` Leonid Yegoshin
2016-01-14 21:36 ` Leonid Yegoshin [this message]
2016-01-14 21:36 ` Leonid Yegoshin
2016-01-14 21:36 ` Leonid Yegoshin
2016-01-14 21:36 ` Leonid Yegoshin
2016-01-14 21:36 ` Leonid Yegoshin
2016-01-14 21:36 ` Leonid Yegoshin
2016-01-14 22:55 ` Paul E. McKenney
2016-01-14 22:55 ` Paul E. McKenney
2016-01-14 22:55 ` Paul E. McKenney
2016-01-14 22:55 ` Paul E. McKenney
2016-01-14 22:55 ` Paul E. McKenney
2016-01-14 22:55 ` Paul E. McKenney
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-14 23:33 ` Leonid Yegoshin
2016-01-15 0:47 ` Paul E. McKenney
2016-01-15 0:47 ` Paul E. McKenney
2016-01-15 0:47 ` Paul E. McKenney
2016-01-15 0:47 ` Paul E. McKenney
2016-01-15 0:47 ` Paul E. McKenney
2016-01-15 0:47 ` Paul E. McKenney
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-15 1:07 ` Leonid Yegoshin
2016-01-27 11:26 ` Maciej W. Rozycki
2016-01-27 11:26 ` Maciej W. Rozycki
2016-01-27 11:26 ` Maciej W. Rozycki
2016-01-27 11:26 ` Maciej W. Rozycki
2016-01-28 0:48 ` Leonid Yegoshin
2016-01-28 0:48 ` Leonid Yegoshin
2016-01-29 13:38 ` Maciej W. Rozycki
2016-01-29 13:38 ` Maciej W. Rozycki
2016-01-29 13:38 ` Maciej W. Rozycki
2016-01-29 13:38 ` Maciej W. Rozycki
2016-01-29 13:38 ` Maciej W. Rozycki
2016-01-29 13:38 ` Maciej W. Rozycki
2016-01-28 0:48 ` Leonid Yegoshin
2016-01-28 0:58 ` Leonid Yegoshin
2016-01-28 0:58 ` Leonid Yegoshin
2016-01-28 0:58 ` Leonid Yegoshin
2016-01-28 0:58 ` Leonid Yegoshin
2016-01-28 0:58 ` Leonid Yegoshin
2016-01-28 0:58 ` Leonid Yegoshin
2016-01-27 11:26 ` Maciej W. Rozycki
2016-01-27 11:26 ` Maciej W. Rozycki
[not found] ` <20160115004753.GN3818-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-01-27 10:40 ` Ralf Baechle
2016-01-27 10:40 ` Ralf Baechle
2016-01-27 10:40 ` Ralf Baechle
2016-01-27 10:40 ` Ralf Baechle
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 12:09 ` Maciej W. Rozycki
2016-01-27 10:40 ` Ralf Baechle
2016-01-27 10:40 ` Ralf Baechle
2016-01-15 10:24 ` Will Deacon
2016-01-15 10:24 ` Will Deacon
2016-01-15 10:24 ` Will Deacon
2016-01-15 17:54 ` Paul E. McKenney
2016-01-15 17:54 ` Paul E. McKenney
2016-01-15 17:54 ` Paul E. McKenney
2016-01-15 17:54 ` Paul E. McKenney
2016-01-15 17:54 ` Paul E. McKenney
2016-01-15 19:28 ` Paul E. McKenney
2016-01-15 19:28 ` Paul E. McKenney
2016-01-15 19:28 ` Paul E. McKenney
2016-01-15 19:28 ` Paul E. McKenney
2016-01-15 19:28 ` Paul E. McKenney
2016-01-25 14:41 ` Will Deacon
2016-01-25 14:41 ` Will Deacon
2016-01-25 14:41 ` Will Deacon
2016-01-25 14:41 ` Will Deacon
2016-01-25 14:41 ` Will Deacon
2016-01-25 14:41 ` Will Deacon
2016-01-26 1:06 ` Paul E. McKenney
2016-01-26 1:06 ` Paul E. McKenney
2016-01-26 1:06 ` Paul E. McKenney
2016-01-26 1:06 ` Paul E. McKenney
2016-01-26 12:10 ` Will Deacon
2016-01-26 12:10 ` Will Deacon
2016-01-26 12:10 ` Will Deacon
2016-01-26 12:10 ` Will Deacon
2016-01-26 12:10 ` Will Deacon
2016-01-26 12:10 ` Will Deacon
2016-01-26 23:37 ` Paul E. McKenney
2016-01-26 23:37 ` Paul E. McKenney
2016-01-26 23:37 ` Paul E. McKenney
2016-01-26 23:37 ` Paul E. McKenney
2016-01-27 10:23 ` Will Deacon
2016-01-27 10:23 ` Will Deacon
2016-01-27 10:23 ` Will Deacon
2016-01-27 10:23 ` Will Deacon
2016-01-27 10:23 ` Will Deacon
2016-01-26 23:37 ` Paul E. McKenney
2016-01-26 1:06 ` Paul E. McKenney
2016-01-26 1:06 ` Paul E. McKenney
2016-01-15 10:24 ` Will Deacon
2016-01-15 8:55 ` Peter Zijlstra
2016-01-15 8:55 ` Peter Zijlstra
2016-01-15 8:55 ` Peter Zijlstra
2016-01-15 8:55 ` Peter Zijlstra
2016-01-15 8:55 ` Peter Zijlstra
2016-01-15 8:55 ` Peter Zijlstra
2016-01-15 9:13 ` Peter Zijlstra
2016-01-15 9:13 ` Peter Zijlstra
2016-01-15 9:13 ` Peter Zijlstra
2016-01-15 9:13 ` Peter Zijlstra
2016-01-15 17:46 ` Paul E. McKenney
2016-01-15 17:46 ` Paul E. McKenney
2016-01-15 17:46 ` Paul E. McKenney
2016-01-15 17:46 ` Paul E. McKenney
2016-01-15 17:46 ` Paul E. McKenney
2016-01-15 21:27 ` Peter Zijlstra
2016-01-15 21:27 ` Peter Zijlstra
2016-01-15 21:27 ` Peter Zijlstra
2016-01-15 21:27 ` Peter Zijlstra
2016-01-15 21:27 ` Peter Zijlstra
2016-01-15 21:58 ` Paul E. McKenney
2016-01-15 21:58 ` Paul E. McKenney
2016-01-15 21:58 ` Paul E. McKenney
2016-01-15 21:58 ` Paul E. McKenney
2016-01-15 21:58 ` Paul E. McKenney
2016-01-25 16:42 ` Will Deacon
2016-01-25 16:42 ` Will Deacon
2016-01-25 16:42 ` Will Deacon
2016-01-25 16:42 ` Will Deacon
2016-01-26 6:03 ` Paul E. McKenney
2016-01-26 6:03 ` Paul E. McKenney
2016-01-26 6:03 ` Paul E. McKenney
2016-01-26 6:03 ` Paul E. McKenney
2016-01-26 6:03 ` Paul E. McKenney
2016-01-26 10:19 ` Peter Zijlstra
2016-01-26 10:19 ` Peter Zijlstra
2016-01-26 10:19 ` Peter Zijlstra
2016-01-26 10:19 ` Peter Zijlstra
2016-01-26 10:19 ` Peter Zijlstra
2016-01-26 10:19 ` Peter Zijlstra
2016-01-26 20:13 ` Paul E. McKenney
2016-01-26 20:13 ` Paul E. McKenney
2016-01-26 20:13 ` Paul E. McKenney
2016-01-26 20:13 ` Paul E. McKenney
2016-01-27 8:39 ` Peter Zijlstra
2016-01-27 8:39 ` Peter Zijlstra
2016-01-27 8:39 ` Peter Zijlstra
2016-01-27 8:39 ` Peter Zijlstra
2016-01-27 8:39 ` Peter Zijlstra
2016-01-27 8:39 ` Peter Zijlstra
2016-01-26 20:13 ` Paul E. McKenney
2016-01-26 12:16 ` Will Deacon
2016-01-26 12:16 ` Will Deacon
2016-01-26 12:16 ` Will Deacon
2016-01-26 12:16 ` Will Deacon
2016-01-26 14:35 ` Boqun Feng
2016-01-26 14:35 ` Boqun Feng
2016-01-26 14:35 ` Boqun Feng
2016-01-26 14:35 ` Boqun Feng
2016-01-26 14:35 ` Boqun Feng
2016-01-26 19:58 ` Paul E. McKenney
2016-01-26 19:58 ` Paul E. McKenney
[not found] ` <20160126121608.GE21553-5wv7dgnIgG8@public.gmane.org>
2016-01-26 19:58 ` Paul E. McKenney
2016-01-26 19:58 ` Paul E. McKenney
2016-01-26 19:58 ` Paul E. McKenney
2016-01-26 19:58 ` Paul E. McKenney
2016-01-27 10:25 ` Will Deacon
2016-01-27 10:25 ` Will Deacon
2016-01-27 10:25 ` Will Deacon
2016-01-27 23:32 ` Paul E. McKenney
2016-01-27 23:32 ` Paul E. McKenney
2016-01-27 23:32 ` Paul E. McKenney
2016-01-27 23:32 ` Paul E. McKenney
2016-01-27 23:32 ` Paul E. McKenney
2016-01-27 10:25 ` Will Deacon
2016-01-15 21:58 ` Paul E. McKenney
2016-01-15 9:13 ` Peter Zijlstra
2016-01-15 17:39 ` Paul E. McKenney
2016-01-15 17:39 ` Paul E. McKenney
2016-01-15 17:39 ` Paul E. McKenney
2016-01-15 17:39 ` Paul E. McKenney
2016-01-15 21:29 ` Peter Zijlstra
2016-01-15 21:29 ` Peter Zijlstra
2016-01-15 21:29 ` Peter Zijlstra
2016-01-15 21:29 ` Peter Zijlstra
2016-01-15 21:29 ` Peter Zijlstra
2016-01-15 22:01 ` Paul E. McKenney
2016-01-15 22:01 ` Paul E. McKenney
2016-01-15 22:01 ` Paul E. McKenney
2016-01-15 22:01 ` Paul E. McKenney
2016-01-15 22:01 ` Paul E. McKenney
2016-01-25 18:02 ` Will Deacon
2016-01-25 18:02 ` Will Deacon
2016-01-25 18:02 ` Will Deacon
2016-01-25 18:02 ` Will Deacon
2016-01-25 18:02 ` Will Deacon
2016-01-25 18:02 ` Will Deacon
2016-01-26 6:12 ` Paul E. McKenney
2016-01-26 6:12 ` Paul E. McKenney
2016-01-26 6:12 ` Paul E. McKenney
2016-01-26 6:12 ` Paul E. McKenney
2016-01-26 6:12 ` Paul E. McKenney
2016-01-26 10:15 ` Peter Zijlstra
2016-01-26 10:15 ` Peter Zijlstra
2016-01-26 10:15 ` Peter Zijlstra
2016-01-26 10:15 ` Peter Zijlstra
2016-01-26 10:15 ` Peter Zijlstra
2016-01-26 10:15 ` Peter Zijlstra
2016-01-26 10:15 ` Peter Zijlstra
2016-01-15 17:39 ` Paul E. McKenney
2016-01-14 21:29 ` Paul E. McKenney
2016-01-14 20:34 ` Paul E. McKenney
2016-01-14 19:28 ` Leonid Yegoshin
2016-01-13 10:45 ` Will Deacon
2016-01-12 20:45 ` Leonid Yegoshin
2016-01-12 11:41 ` Will Deacon
2016-01-12 10:25 ` Peter Zijlstra
2016-01-12 10:25 ` Peter Zijlstra
2016-01-12 9:27 ` Peter Zijlstra
2016-01-12 1:14 ` Leonid Yegoshin
2016-01-12 1:14 ` Leonid Yegoshin
2016-01-10 14:18 ` [PATCH v3 11/41] " Michael S. Tsirkin
2016-01-10 14:18 ` [PATCH v3 12/41] x86/um: " Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` [PATCH v3 13/41] x86: " Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-12 14:10 ` Thomas Gleixner
2016-01-12 14:10 ` Thomas Gleixner
2016-01-12 14:10 ` Thomas Gleixner
2016-01-12 14:10 ` Thomas Gleixner
2016-01-12 14:10 ` Thomas Gleixner
2016-01-12 14:10 ` Thomas Gleixner
2016-01-12 14:10 ` Thomas Gleixner
2016-01-10 14:18 ` [PATCH v3 14/41] asm-generic: add __smp_xxx wrappers Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` [PATCH v3 15/41] powerpc: define __smp_xxx Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` [PATCH v3 16/41] arm64: " Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` [PATCH v3 17/41] arm: " Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:18 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 18/41] blackfin: " Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 19/41] ia64: " Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 20/41] metag: " Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 21/41] mips: " Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 22/41] s390: " Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 23/41] sh: define __smp_xxx, fix smp_store_mb for !SMP Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` [PATCH v3 24/41] sparc: define __smp_xxx Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:19 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 25/41] tile: " Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 26/41] xtensa: " Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 27/41] x86: " Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-12 14:11 ` Thomas Gleixner
2016-01-12 14:11 ` Thomas Gleixner
2016-01-12 14:11 ` Thomas Gleixner
2016-01-12 14:11 ` Thomas Gleixner
2016-01-12 14:11 ` Thomas Gleixner
2016-01-12 14:11 ` Thomas Gleixner
2016-01-10 14:20 ` [PATCH v3 28/41] asm-generic: implement virt_xxx memory barriers Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 29/41] Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb" Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 30/41] virtio_ring: update weak barriers to use virt_xxx Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 31/41] sh: support 1 and 2 byte xchg Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` [PATCH v3 32/41] sh: move xchg_cmpxchg to a header by itself Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:20 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 33/41] virtio_ring: use virt_store_mb Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 34/41] checkpatch.pl: add missing memory barriers Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 35/41] checkpatch: check for __smp outside barrier.h Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 36/41] checkpatch: add virt barriers Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 37/41] xenbus: use virt_xxx barriers Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 38/41] xen/io: " Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` [PATCH v3 39/41] xen/events: " Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-11 11:12 ` David Vrabel
2016-01-11 11:12 ` David Vrabel
2016-01-11 11:12 ` David Vrabel
2016-01-11 11:12 ` David Vrabel
2016-01-11 11:12 ` David Vrabel
2016-01-11 11:12 ` David Vrabel
2016-01-10 14:21 ` Michael S. Tsirkin
2016-01-10 14:22 ` [PATCH v3 40/41] s390: use generic memory barriers Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` [PATCH v3 41/41] s390: more efficient smp barriers Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-10 14:22 ` Michael S. Tsirkin
2016-01-12 12:50 ` [PATCH v3 00/41] arch: barrier cleanup + barriers for virt Peter Zijlstra
2016-01-12 12:50 ` Peter Zijlstra
2016-01-12 12:50 ` Peter Zijlstra
2016-01-12 12:50 ` Peter Zijlstra
2016-01-12 12:50 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569814F2.50801@imgtec.com \
--to=leonid.yegoshin@imgtec.com \
--cc=adi-buildroot-devel@lists.sourceforge.net \
--cc=arnd@arndb.de \
--cc=ddaney.cavm@gmail.com \
--cc=hpa@zytor.com \
--cc=james.hogan@imgtec.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-metag@vger.kernel.orglinux-a \
--cc=linux-mips@linux-mips.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=mst@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tglx@linutronix.de \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=virtualization@lists.linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.