On 03/26/2018 08:39 PM, Nicholas Piggin wrote:
xmon can be entered via sreset NMI (from a management sreset, or an
NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc
or sp are within OPAL memory, and if so, then use OPAL_DEBUG to
print the opal stack and return the Linux stack, w
On 03/26/2018 08:32 PM, Nicholas Piggin wrote:
opal_nvram_write currently just assumes success if it encounters an
error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
on other errors instead.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
On Tue, 27 Mar 2018 12:42:32 +0530
Vasant Hegde wrote:
> On 03/26/2018 08:39 PM, Nicholas Piggin wrote:
> > xmon can be entered via sreset NMI (from a management sreset, or an
> > NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc
> > or sp are within OPAL memory, and if so, then
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
> Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
fyi: It's marked Maintained in MAINTAINERS
HARDWARE MONITORING
M: Jean Delvare
M: Guenter Roeck
L: linux-hw...@vger.kernel.org
W: http://hwm
On Tue, 27 Mar 2018 12:47:31 +0530
Vasant Hegde wrote:
> On 03/26/2018 08:32 PM, Nicholas Piggin wrote:
> > opal_nvram_write currently just assumes success if it encounters an
> > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> > on other errors instead.
> >
> > Signed-off-b
On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
>
> I even see patches adding wmb() based on actual observed memory
> corruption during testing on Intel:
>
> h
[ This is really really ancient code. - dan ]
Hello Rupjyoti Sarmah,
The patch 3fb7933850fa: "powerpc/4xx: Adding PCIe MSI support" from
Mar 29, 2011, leads to the following static checker warning:
arch/powerpc/platforms/4xx/msi.c:100 ppc4xx_setup_msi_irqs()
warn: 'int_no >= 0'
Christophe,
On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe
wrote:
> Mathieu Malaterre a écrit :
>
>
>> On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy
>> wrote:
>>>
>>>
>>>
>>> Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
Some functions prototypes were missing for the
/commits/Michael-Ellerman/powerpc-Add-security-feature-flags-for-Spectre-Meltdown/20180327-041008
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-g5_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce
Hi Mathieu,
Mathieu Malaterre writes:
> On Thu, Mar 8, 2018 at 11:36 AM, Michael Ellerman wrote:
>> Mathieu Malaterre writes:
>>> On Sun, Mar 4, 2018 at 11:54 AM, Michael Ellerman
>>> wrote:
Mathieu Malaterre writes:
> In commit 81e7009ea46c ("powerpc: merge ppc signal.c and ppc64
On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
> > > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
> >
> > I even see patches adding wmb() based o
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> Current
This patch series provides arch-neutral enhancements to
enable memory-keys on new architecutes, and the corresponding
changes in x86 and powerpc specific code to support that.
a) Provides ability to support upto 32 keys. PowerPC
can handle 32 keys and hence needs this.
b) Arch-neutral co
VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
is enabled. Powerpc also needs these bits. Hence lets define the
VM_PKEY_BITx bits for any architecture that enables
CONFIG_ARCH_HAS_PKEYS.
cc: Michael Ellermen
cc: Benjamin Herrenschmidt
cc: Andrew Morton
Reviewed-by: Dav
Currently only 4bits are allocated in the vma flags to hold 16
keys. This is sufficient for x86. PowerPC supports 32 keys,
which needs 5bits. This patch allocates an additional bit.
cc: Dave Hansen
cc: Michael Ellermen
cc: Benjamin Herrenschmidt
cc: Andrew Morton
Reviewed-by: Ingo Molnar
Currently the architecture specific code is expected to
display the protection keys in smap for a given vma.
This can lead to redundant code and possibly to divergent
formats in which the key gets displayed.
This patch changes the implementation. It displays the
pkey only if the archite
On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
> >> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
> >
> > I even see patches adding wmb() ba
On Tue, Mar 27, 2018 at 10:56 AM, Benjamin Herrenschmidt
wrote:
> On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:
>> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
>>
>> I'm pretty sure I've never seen
>> any bug reports pointing to a missing wmb() between memory
>> and MMIO wri
[+ locking/ordering/docs people]
On Tue, Mar 27, 2018 at 07:56:59PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:
> > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wr
On Tue, Mar 27, 2018 at 11:44:22AM +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 10:56 AM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:
> >> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> >>
> >> I'm pretty sure I've never seen
>
On Tue, Mar 27, 2018 at 11:57 AM, Will Deacon wrote:
>
> From db0daeaf94f0f6232f8206fc07a74211324b11d9 Mon Sep 17 00:00:00 2001
> From: Will Deacon
> Date: Tue, 27 Mar 2018 10:49:58 +0100
> Subject: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering
> example
>
> The section of m
On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 11:57 AM, Will Deacon wrote:
>
> >
> > From db0daeaf94f0f6232f8206fc07a74211324b11d9 Mon Sep 17 00:00:00 2001
> > From: Will Deacon
> > Date: Tue, 27 Mar 2018 10:49:58 +0100
> > Subject: [PATCH] docs/memory-
On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote:
> kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI.
> If CPU is in extended quiescent state (idle task or nohz_full userspace), this
> work may be done at the exit of this state. Delaying synchronization helps t
On 03/27/2018 12:35 AM, Joe Perches wrote:
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
fyi: It's marked Maintained in MAINTAINERS
I did not say that it was not maintained, and I am aware of the informat
On Tue, Mar 27, 2018 at 12:09 PM, Will Deacon wrote:
> On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote:
>> > -
>> > - See Documentation/DMA-API.txt for more information on consistent
>> > memory.
>> > + can see it now has ownership. Note that, when using writel(), a
>> > p
On Tue, Mar 27, 2018 at 12:53:49PM +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 12:09 PM, Will Deacon wrote:
> > On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote:
> >> > -
> >> > - See Documentation/DMA-API.txt for more information on consistent
> >> > memory.
> >> > +
On Tue, Mar 27, 2018 at 1:02 PM, Will Deacon wrote:
> On Tue, Mar 27, 2018 at 12:53:49PM +0200, Arnd Bergmann wrote:
>> On Tue, Mar 27, 2018 at 12:09 PM, Will Deacon wrote:
>> > On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote:
> diff --git a/Documentation/memory-barriers.txt
> b/D
On Tue, 2018-03-27 at 10:42 +0100, Will Deacon wrote:
> >
> > This example adds a wmb() between two writes to a coherent DMA
> > area, it is definitely required there. I'm pretty sure I've never seen
> > any bug reports pointing to a missing wmb() between memory
> > and MMIO write accesses, but if
On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote:
> > The interesting thing is that we do seem to have a whole LOT of these
> > spurrious wmb before writel all over the tree, I suspect because of
> > that incorrect recommendation in memory-barriers.txt.
> >
> > We should fix that.
>
> Maybe
On Tue, Mar 27, 2018 at 10:20:02PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2018-03-27 at 10:42 +0100, Will Deacon wrote:
> > >
> > > This example adds a wmb() between two writes to a coherent DMA
> > > area, it is definitely required there. I'm pretty sure I've never seen
> > > any bug repo
On Tue, 2018-03-27 at 12:02 +0100, Will Deacon wrote:
> can see it now has ownership. Note that, when using writel(), a prior
> > wmb() is not needed to guarantee that the cache coherent memory writes
> > have completed before writing to the cache incoherent MMIO region.
> >
On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote:
> On 03/27/2018 12:35 AM, Joe Perches wrote:
> > On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
> > > Since the hwmon subsystem has been labeled as both "obsolete" and
> > > "obscure",
> >
> > fyi: It's marked Maintained in MAINTAIN
On Tue, 2018-03-27 at 10:57 +0100, Will Deacon wrote:
> >
> > The interesting thing is that we do seem to have a whole LOT of these
> > spurrious wmb before writel all over the tree, I suspect because of
> > that incorrect recommendation in memory-barriers.txt.
> >
> > We should fix that.
>
> Pa
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source for details.
Arguably these could be firmware features, but
Add some additional values which have been defined for the
H_GET_CPU_CHARACTERISTICS hypercall.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/hvcall.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
inde
Now that we have feature flags for security related things, set or
clear them based on what we receive from the hypercall.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/setup.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/power
Now that we have feature flags for security related things, set or
clear them based on what we see in the device tree provided by
firmware.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powernv/setup.c | 56 ++
1 file changed, 56 insertions(+)
diff -
Now that we have the security feature flags we can make the
information displayed in the "meltdown" file more informative.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/security_features.h | 1 +
arch/powerpc/kernel/security.c | 30 ++--
2 fi
This landed in setup_64.c for no good reason other than we had nowhere
else to put it. Now that we have a security-related file, that is a
better place for it so move it.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/security.c | 11 +++
arch/powerpc/kernel/setup_64.c | 8
Now that we have the security flags we can significantly simplify the
code in pnv_setup_rfi_flush(), because we can use the flags instead of
checking device tree properties and because the security flags have
pessimistic defaults.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powern
Now that we have the security flags we can simplify the code in
pseries_setup_rfi_flush() because the security flags have pessimistic
defaults.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/setup.c | 27 ---
1 file changed, 12 insertions(+), 15 deleti
Add a definition for cpu_show_spectre_v1() to override the generic
version. Currently this just prints "Not affected" or "Vulnerable"
based on the firmware flag.
Although the kernel does have array_index_nospec() in a few places, we
haven't yet audited all the powerpc code to see where it's necess
Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
The most verbose is:
Mitigation: Indirect branch serialisation (kernel only), Indirect
branch cache disabled, ori31 spe
Nicholas Piggin writes:
> opal_nvram_write currently just assumes success if it encounters an
> error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> on other errors instead.
Does that ever happen with current skiboot?
Even if it doesn't I think I'm inclined to tag this for stabl
On 2018-03-27 07:23, Benjamin Herrenschmidt wrote:
On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote:
> The interesting thing is that we do seem to have a whole LOT of these
> spurrious wmb before writel all over the tree, I suspect because of
> that incorrect recommendation in memory-barri
On Tue, 27 Mar 2018 23:13:00 +1100
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > opal_nvram_write currently just assumes success if it encounters an
> > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> > on other errors instead.
>
> Does that ever happen with cu
> Fair enough. I'd rather people used _relaxed by default, but I have to admit
> that it will probably just result in them getting things wrong...
Certainly requiring the driver writes use explicit barriers should make
them understand when and why they are needed - and then put in the correct ones
On 3/27/2018 7:02 AM, Will Deacon wrote:
> - See Documentation/DMA-API.txt for more information on consistent memory.
> + can see it now has ownership. Note that, when using writel(), a prior
> + wmb() is not needed to guarantee that the cache coherent memory writes
> + have comple
On Tue, Mar 27, 2018 at 11:01:44PM +1100, Michael Ellerman wrote:
> This commit adds security feature flags to reflect the settings we
> receive from firmware regarding Spectre/Meltdown mitigations.
>
> The feature names reflect the names we are given by firmware on bare
> metal machines. See the
On Tue, Mar 27, 2018 at 08:22:55AM -0400, ok...@codeaurora.org wrote:
> On 2018-03-27 07:23, Benjamin Herrenschmidt wrote:
> >On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote:
> >>> The interesting thing is that we do seem to have a whole LOT of these
> >>> spurrious wmb before writel all ove
On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
> >> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
> >
> > I even see patches adding wmb() ba
On Tue, Mar 27, 2018 at 10:42:00AM +0100, Will Deacon wrote:
> On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote:
> > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote:
> > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
> > >> On Mon, 2018-03-26 at 17:4
On Tue, Mar 27, 2018 at 09:46:51AM -0400, Sinan Kaya wrote:
> On 3/27/2018 7:02 AM, Will Deacon wrote:
> > - See Documentation/DMA-API.txt for more information on consistent
> > memory.
> > + can see it now has ownership. Note that, when using writel(), a prior
> > + wmb() is not need
+netdev, +Alex
On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote:
>> Most of the drivers have a unwound loop with writeq() or something to
>>> do it.
>>
>> But isn't the writeq() barrier much more expensive than anything you'd
>> do in fu
On Tue, Mar 27, 2018 at 9:24 AM, Rob Herring wrote:
> On Fri, Mar 23, 2018 at 07:12:09PM +1100, Oliver O'Halloran wrote:
>> Add device-tree binding documentation for the nvdimm region driver.
>>
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Oliver O'Halloran
>> ---
>> .../devicetree/bindin
Hi Alex,
On Tue, Mar 27, 2018 at 10:46:58AM -0400, Sinan Kaya wrote:
> +netdev, +Alex
>
> On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote:
> >> Most of the drivers have a unwound loop with writeq() or something to
> >>> do it.
> >>
>
Shile Zhang a écrit :
fix the missed point in Paul's patch:
"powerpc/64: Fix checksum folding in csum_tcpudp_nofold and
ip_fast_csum_nofold"
Signed-off-by: Shile Zhang
---
arch/powerpc/include/asm/checksum.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/inc
On 03/27/2018 04:48 AM, Joe Perches wrote:
On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote:
On 03/27/2018 12:35 AM, Joe Perches wrote:
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
fyi: It's marked
Mathieu Malaterre a écrit :
Christophe,
On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe
wrote:
Mathieu Malaterre a écrit :
On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy
wrote:
Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
Some functions prototypes were missing for the
From: Boqun Feng
Call the rseq_handle_notify_resume() function on return to userspace if
TIF_NOTIFY_RESUME thread flag is set.
Increment the event counter and perform fixup on the pre-signal when a
signal is delivered on top of a restartable sequence critical section.
Signed-off-by: Boqun Feng
From: Boqun Feng
Wire up the rseq system call on powerpc.
This provides an ABI improving the speed of a user-space getcpu
operation on powerpc by skipping the getcpu system call on the fast
path, as well as improving the speed of user-space operations on per-cpu
data compared to using load-reser
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Boqun Feng
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arc
On Tue, 2018-03-27 at 08:44 -0700, Guenter Roeck wrote:
> On 03/27/2018 04:48 AM, Joe Perches wrote:
> > On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote:
> > > On 03/27/2018 12:35 AM, Joe Perches wrote:
> > > > On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
> > > > > Since the hwmon
Le 22/03/2018 à 22:05, Mathieu Malaterre a écrit :
In commit 14baf4d9c739 ("cxl: Add guest-specific code") the following code
was added:
if (afu->crs_len < 0) {
dev_err(&afu->dev, "Unexpected configuration record size
value\n");
return -EINVAL;
> On 27 Mar 2018, at 10:24, Michal Hocko wrote:
>
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>
>>> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
>>>
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote:
>
> On Thu, Mar 22, 20
Hi,
On 27-03-2018 15:46, Sinan Kaya wrote:
>
> Sinan
> "We are being told that if you use writel(), then you don't need a wmb() on
> all architectures."
>
> Alex:
> "I'm not sure who told you that but that is incorrect, at least for
> x86. If you attempt to use writel() without the wmb() we will h
unscribed me
On Tuesday, March 27, 2018 05:34:30 AM PDT, Michael
Ellerman wrote:
Nicholas Piggin writes:
> opal_nvram_write currently just assumes success if it encounters an
> error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO
> on other errors inst
unscribed me
On Tuesday, March 27, 2018 05:31:31 AM PDT, Michael
Ellerman wrote:
Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
The most ver
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
> >>>
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
> > On 23 Mar 2018,
LEROY Christophe a écrit :
Mathieu Malaterre a écrit :
Christophe,
On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe
wrote:
Mathieu Malaterre a écrit :
On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy
wrote:
Le 22/03/2018 à 21:20, Mathieu Malaterre a écrit :
Some functions pr
Ram Pai writes:
> On Fri, Feb 23, 2018 at 03:33:43PM -0300, Thiago Jung Bauermann wrote:
>> This test exercises read and write access to the AMR, IAMR and UAMOR.
>>
>
> Tested-by: Ram Pai
> Acked-by: Ram Pai
Ping? Can this and patch 2/2 go in v4.17?
>> Signed-off-by: Thiago Jung Bauermann
On Tue, Mar 27, 2018 at 8:10 AM, Will Deacon wrote:
> Hi Alex,
>
> On Tue, Mar 27, 2018 at 10:46:58AM -0400, Sinan Kaya wrote:
>> +netdev, +Alex
>>
>> On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote:
>> > On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote:
>> >> Most of the drivers have a
On 26.03.2018 01:37, Linus Torvalds wrote:
> […] Anyway. Go out and test. And let's hope next week is nice and calm and
> I can release the final 4.16 next Sunday without any extra rc's.
>
>Linus
Hi! Find below my sixth regression report for Linux 4.16. It lists 7
regressions I'm
Hi,
On Mon, Mar 19, 2018 at 10:19:32PM +1100, Michael Ellerman wrote:
> Michael Ellerman writes:
> > Jonathan Neuschäfer writes:
[...]
> >> - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
> >> + if (page_is_ram(__phys_to_pfn(p)) &&
> >>!(__allow_ioremap_reserved && memb
On Tue, 27 Mar 2018 15:29:06 +1100
Michael Ellerman wrote:
> We've had dynamic ftrace support for over 9 years since Steve first
> wrote it, all the distros use dynamic, and static is basically
> untested these days, so drop support for static ftrace.
>
> Signed-off-by: Michael Ellerman
Acked-
On Tue, Mar 27, 2018 at 8:54 PM, Alexander Duyck
wrote:
> On Tue, Mar 27, 2018 at 8:10 AM, Will Deacon wrote:
>>>
>>> Sinan
>>> "We are being told that if you use writel(), then you don't need a wmb() on
>>> all architectures."
>>>
>>> Alex:
>>> "I'm not sure who told you that but that is incorr
On Tue, Mar 27, 2018 at 9:54 PM, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 8:54 PM, Alexander Duyck
> wrote:
>> On Tue, Mar 27, 2018 at 8:10 AM, Will Deacon wrote:
>
> 11.10 STORE BUFFER
> Intel 64 and IA-32 processors temporarily store each write (store) to
> memory in a store buffer. The
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 2f3e98edc94a..b6432a261e63 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1199,6 +1199,7 @@ static inline void clear_page_pfmemalloc(struct page
> *page)
> #define VM_FAU
On Tue, 2018-03-27 at 09:46 -0400, Sinan Kaya wrote:
> On 3/27/2018 7:02 AM, Will Deacon wrote:
> > - See Documentation/DMA-API.txt for more information on consistent
> > memory.
> > + can see it now has ownership. Note that, when using writel(), a prior
> > + wmb() is not needed to g
On Tue, 2018-03-27 at 08:12 -0600, Jason Gunthorpe wrote:
> > I have been converting wmb+writel to wmb+writel_relaxed. (About 30 patches)
> >
> > I will have to just remove the wmb and keep writel, then repost.
>
> Okay, but before you do that, can we get a statement how this works
> for WC?
>
>
On Tue, 2018-03-27 at 15:36 +0100, Will Deacon wrote:
> > Can we say the same thing for iowrite32() and iowrite32be(). I also see
> > wmb()
> > in front of these.
>
> I don't think so. My reading of memory-barriers.txt says that writeX might
> expand to outX, and outX is not ordered with respect
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> index faf85699f1a1..5898255d0aeb 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -558,6 +558,10 @@ void __vma_link_rb(struct mm_struct *mm, struct
> vm_area_struct *vma,
> else
> mm->highest_vm_e
On Tue, 2018-03-27 at 11:54 -0700, Alexander Duyck wrote:
> As far as I know the code has been this way for a while, something
> like 2002, when the barrier was already present in e1000. However
> there it was calling out weakly ordered models "such as IA-64". Since
> then pretty much all the hardw
On Tue, 2018-03-27 at 10:46 -0400, Sinan Kaya wrote:
> combined buffers.
>
> Alex:
> "Don't bother. I can tell you right now that for x86 you have to have a
> wmb() before the writel().
No, this isn't the semantics of writel. You shouldn't need it unless
something changed and we need to revisit
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 65ae54659833..a2d9c87b7b0b 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1136,8 +1136,11 @@ static ssize_t clear_refs_write(struct file *file,
> const char __user *buf,
>
On Tue, Mar 27, 2018 at 2:35 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2018-03-27 at 10:46 -0400, Sinan Kaya wrote:
>> combined buffers.
>>
>> Alex:
>> "Don't bother. I can tell you right now that for x86 you have to have a
>> wmb() before the writel().
>
> No, this isn't the semantics of write
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 5898255d0aeb..d6533cb85213 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -847,17 +847,18 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
> long start,
> }
>
> if (start != vma->vm_star
On Tue, 13 Mar 2018, Laurent Dufour wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 88042d843668..ef6ef0627090 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2189,16 +2189,24 @@ void anon_vma_interval_tree_verify(struct
> anon_vma_chain *node);
> extern
On 3/27/2018 5:54 PM, Alexander Duyck wrote:
> I view the wmb() + writel_relaxed() as more of a driver owning and
> handling this itself. Besides in the Intel Ethernet driver case it is
> better performance as our wmb() placement for us also provides a
> secondary barrier so we don't need to add a
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a
> performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secu
On Tue, Mar 27, 2018 at 6:51 AM, Ilya Smith wrote:
>
>> On 27 Mar 2018, at 10:24, Michal Hocko wrote:
>>
>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>
On 26 Mar 2018, at 11:46, Michal Hocko wrote:
On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
>> On 23 Mar 2018, at 15:
On Tue, 2018-03-27 at 14:54 -0700, Alexander Duyck wrote:
> On Tue, Mar 27, 2018 at 2:35 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2018-03-27 at 10:46 -0400, Sinan Kaya wrote:
> > > combined buffers.
> > >
> > > Alex:
> > > "Don't bother. I can tell you right now that for x86 you have to h
v1: https://www.spinics.net/lists/linux-mm/msg145939.html
This patchset makes it possible to allocate MMIO ranges that are between
the two RAM chunks on the Wii, MEM1 and MEM2, not only with ioremap
(which previously worked through a hack) but also with kernel/resource.c.
Changes in v2:
- I added
Instead of open-coding the search in page_is_ram, call memblock_is_memory.
Signed-off-by: Jonathan Neuschäfer
---
v2: no changes
---
arch/powerpc/mm/mem.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index fe8c61149fb8.
Because the two memory blocks (usually called MEM1 and MEM2) are not
merged anymore, __request_region in kernel/resource.c will correctly
allow reserving regions in the physical address space between MEM1 and
MEM2, where many important peripherals are (GPIO, MMC, USB, ...).
A previous change to __
To support accurate checking for different blocks of memory on PPC32,
use the same memblock-based approach that's already used on PPC64 also
on PPC32.
Signed-off-by: Jonathan Neuschäfer
---
v2: no changes
---
arch/powerpc/mm/mem.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powe
This hack, introduced in commit c5df7f775148 ("powerpc: allow ioremap
within reserved memory regions") is now unnecessary.
Signed-off-by: Jonathan Neuschäfer
---
v2: no changes
---
arch/powerpc/mm/init_32.c| 5 -
arch/powerpc/mm/mmu_decl.h | 1 -
arch/powerpc/mm/pgtable_32.c | 3 +--
On systems where there is MMIO space between different blocks of RAM in
the physical address space, __ioremap_caller did not allow mapping these
MMIO areas, because they were below the end RAM and thus considered RAM
as well. Use the memblock-based page_is_ram function, which returns
false for suc
On Tue, Mar 27, 2018 at 11:33 AM, Benjamin Herrenschmidt
wrote:
>
> Well, we need to clarify that once and for all, because as I wrote
> earlier, it was decreed by Linus more than a decade ago that writel
> would be fully ordered by itself vs. previous memory stores (at least
> on UC memory).
Yes
From: Gavin Shan
The value passed to __raw_rm_writeq() and __raw_writeq() should be "u64"
and "unsigned long". This fixes warning reported by sparse:
gwshan@gwshan:~/sandbox/l$ make C=2 CF=-D__CHECK_ENDIAN__ \
arch/powerpc/platforms/powernv/pci-ioda.o
arch/powerp
1 - 100 of 119 matches
Mail list logo
