On Wed, 2018-03-28 at 06:53 +, Linus Torvalds wrote:
>
>
> On Tue, Mar 27, 2018, 20:43 Benjamin Herrenschmidt ing.org> wrote:
> > >
> > > Of course, you'd have to be pretty odd to want to start a DMA
> > with a
> > > read anyway - partly exactly because it's bad for performance
> > since
> >
On Tue, 2018-03-27 at 20:26 -1000, Linus Torvalds wrote:
> On Tue, Mar 27, 2018 at 6:33 PM, Benjamin Herrenschmidt
> wrote:
> >
> > This is why, I want (with your agreement) to define clearly and once
> > and for all, that the Linux semantics of writel are that it is ordered
> > with previous wri
On Tue, Mar 27, 2018 at 6:33 PM, Benjamin Herrenschmidt
wrote:
>
> This is why, I want (with your agreement) to define clearly and once
> and for all, that the Linux semantics of writel are that it is ordered
> with previous writes to coherent memory (*)
Honestly, I think those are the sane seman
On Tue, Mar 27, 2018 at 5:24 PM, Sinan Kaya wrote:
>
> Basically changing it to
>
> dma_buffer->foo = 1;/* WB */
> wmb()
> writel_relaxed(KICK, DMA_KICK_REGISTER);/* UC */
> mmiowb()
Why?
Why not just remove the wmb(), and keep the barrier in the writel()?
The above
Matt Evans writes:
> When using SIG_DBG_BRANCH_TRACING, MSR.BE is left enabled in the
> user context when single_step_exception() prepares the SIGTRAP
> delivery. The resulting branch-trap-within-the-SIGTRAP-handler
> isn't healthy.
>
> Commit 2538c2d08f46141550a1e68819efa8fe31c6e3dc broke this,
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
Current implementation doesn't randomize address retur
Paul Mackerras writes:
> 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/platfo
On Tue, 2018-03-27 at 23:24 -0400, Sinan Kaya wrote:
> On 3/27/2018 10:51 PM, Linus Torvalds wrote:
> > > The discussion at hand is about
> > >
> > > dma_buffer->foo = 1;/* WB */
> > > writel(KICK, DMA_KICK_REGISTER);/* UC */
> >
> > Yes. That certainly
On Tue, 2018-03-27 at 16:51 -1000, Linus Torvalds wrote:
> On Tue, Mar 27, 2018 at 3:03 PM, Benjamin Herrenschmidt
> wrote:
> >
> > The discussion at hand is about
> >
> > dma_buffer->foo = 1;/* WB */
> > writel(KICK, DMA_KICK_REGISTER);/* UC */
>
> Y
On 3/27/2018 10:51 PM, Linus Torvalds wrote:
>> The discussion at hand is about
>>
>> dma_buffer->foo = 1;/* WB */
>> writel(KICK, DMA_KICK_REGISTER);/* UC */
> Yes. That certainly is ordered on x86. In fact, afaik it's ordered
> even if that writel() mig
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> > I agree: pushing this off to libc leaves a lot of things unprotected.
> > I think this should live in the kernel. The question I have is about
> > making it maintainable/
On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote:
> 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
On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/et
On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> I agree: pushing this off to libc leaves a lot of things unprotected.
> I think this should live in the kernel. The question I have is about
> making it maintainable/readable/etc.
>
> The state-of-the-art for ASLR is moving to finer gran
New changes to %p cause the information printed at boot
about radix-mmu partition and process table opaque, if
we really want to protect those values, we should make
dmesg more secure using CONFIG_SECURITY_DMESG_RESTRICT
Before the patches:
radix-mmu: Partition table (ptrval)
radix-mmu: P
On Tue, Mar 27, 2018 at 3:03 PM, Benjamin Herrenschmidt
wrote:
>
> The discussion at hand is about
>
> dma_buffer->foo = 1;/* WB */
> writel(KICK, DMA_KICK_REGISTER);/* UC */
Yes. That certainly is ordered on x86. In fact, afaik it's ordered
even if tha
On Tue, 2018-03-27 at 16:10 +0100, Will Deacon wrote:
> To clarify: are you saying that on x86 you need a wmb() prior to a writel
> if you want that writel to be ordered after prior writes to memory? Is this
> specific to WC memory or some other non-standard attribute?
>
> The only reason we have
On 28/3/18 11:44 am, Paul Mackerras wrote:
> 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__ \
>
On Tue, 2018-03-27 at 14:39 -1000, Linus Torvalds wrote:
> 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 ordere
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
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
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
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 +--
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
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 __
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.
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
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
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, 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 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, 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 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, 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/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, 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, 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, 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 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, 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 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, 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, 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, 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, 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-
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 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
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
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
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
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,
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
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
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
> 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
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 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
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
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
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
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
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
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
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.
> >>
>
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
+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 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
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: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 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 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 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
> 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 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
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
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
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
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
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
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
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 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
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 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
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
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
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
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 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, 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 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, 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, 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, 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 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 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 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 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 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 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
>
1 - 100 of 119 matches
Mail list logo
