* Re: RFC on writel and writel_relaxed
From: Jason Gunthorpe @ 2018-03-28 16:57 UTC (permalink / raw)
To: Will Deacon
Cc: Benjamin Herrenschmidt, Arnd Bergmann, Sinan Kaya, David Laight,
Oliver, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Paul E. McKenney, Peter Zijlstra,
Ingo Molnar, Jonathan Corbet
In-Reply-To: <20180328101345.GA30850@arm.com>
On Wed, Mar 28, 2018 at 11:13:45AM +0100, Will Deacon wrote:
> On Wed, Mar 28, 2018 at 09:01:27PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2018-03-28 at 11:55 +0200, Arnd Bergmann wrote:
> > > > powerpc and ARM can't quite make them synchronous I think, but at least
> > > > they should have the same semantics as writel.
> > >
> > > One thing that ARM does IIRC is that it only guarantees to order writel() within
> > > one device, and the memory mapped PCI I/O space window almost certainly
> > > counts as a separate device to the CPU.
> >
> > That sounds bogus.
>
> To elaborate, if you do the following on arm:
>
> writel(DEVICE_FOO);
> writel(DEVICE_BAR);
>
> we generally cannot guarantee in which order those accesses will hit the
> devices even if we add every barrier under the sun. You'd need something
> in between, specific to DEVICE_FOO (probably a read-back) to really push
> the first write out. This doesn't sound like it would be that uncommon to
> me.
The PCI posted write does not require the above to execute 'in order'
only that any bus segment shared by the two devices have the writes
issued in CPU order. ie at a shared PCI root port for instance.
If I recall this is very similar to the ordering that ARM's on-chip
AXI interconnect is supposed to provide.. So I'd be very surprised if
a modern ARM64 has an meaningful difference from x86 here.
When talking about ordering between the devices, the relevant question
is what happens if the writel(DEVICE_BAR) triggers DEVICE_BAR to DMA
from the DEVICE_FOO. 'ordered' means that in this case
writel(DEVICE_FOO) must be presented to FOO before anything generated
by BAR.
Jason
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Russell King - ARM Linux @ 2018-03-28 16:48 UTC (permalink / raw)
To: Rob Landley
Cc: Shea Levy, linux-riscv, linux-kernel, Christoph Hellwig,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Catalin Marinas, Will Deacon, Mark Salter, Aurelien Jacquiot,
Mikael Starvik, Jesper Nilsson, Yoshinori Sato, Richard Kuo,
Tony Luck, Fenghua Yu, Geert Uytterhoeven, James Hogan,
Michal Simek, Ralf Baechle, David Howells, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens, Chen Liqin, Lennox Wu,
Rich Felker, David S. Miller, Jeff Dike, Richard Weinberger,
Guan Xuetao, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Chris Zankel, Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches,
Oliver O'Halloran, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, linux-alpha, linux-snps-arc,
linux-arm-kernel, adi-buildroot-devel, linux-c6x-dev,
linux-cris-kernel, uclinux-h8-devel, linux-hexagon, linux-ia64,
linux-m68k, linux-metag, linux-mips, linux-am33-list, nios2-dev,
openrisc, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa
In-Reply-To: <05620fee-e8b5-0668-77b8-da073dc78c40@landley.net>
On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > Now only those architectures that have custom initrd free requirements
> > need to define free_initrd_mem.
> ...
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> > {
> > free_initmem_default(-1);
> > }
> > -
> > -#ifdef CONFIG_BLK_DEV_INITRD
> > -void __init free_initrd_mem(unsigned long start, unsigned long end)
> > -{
> > - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > -}
> > -#endif
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 3f972e83909b..19d1c5594e2d 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -47,6 +47,7 @@ config ARM
> > select HARDIRQS_SW_RESEND
> > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> > + select HAVE_ARCH_FREE_INITRD_MEM
> > select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> > select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > select HAVE_ARCH_MMAP_RND_BITS if MMU
>
> Isn't this why weak symbols were invented?
Weak symbols means that we end up with both the weakly-referenced code
and the arch code in the kernel image. That's fine if the weak code
is small.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 6/6] doc/devicetree: NVDIMM region documentation
From: Rob Herring @ 2018-03-28 17:06 UTC (permalink / raw)
To: Oliver; +Cc: linux-nvdimm@lists.01.org, Device Tree, linuxppc-dev,
Dan Williams
In-Reply-To: <CAOSf1CFpFwzLMx0xmM+JmbQCiOA=QU_S5g0uf-qx181vJ_Xc1w@mail.gmail.com>
On Tue, Mar 27, 2018 at 9:53 AM, Oliver <oohall@gmail.com> wrote:
> On Tue, Mar 27, 2018 at 9:24 AM, Rob Herring <robh@kernel.org> 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: devicetree@vger.kernel.org
>>> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>>> ---
>>> .../devicetree/bindings/nvdimm/nvdimm-region.txt | 45 ++++++++++++++++++++++
>>> 1 file changed, 45 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/nvdimm/nvdimm-region.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvdimm/nvdimm-region.txt b/Documentation/devicetree/bindings/nvdimm/nvdimm-region.txt
>>> new file mode 100644
>>> index 000000000000..02091117ff16
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/nvdimm/nvdimm-region.txt
>>> @@ -0,0 +1,45 @@
>>> +Device-tree bindings for NVDIMM memory regions
>>> +-----------------------------------------------------
>>> +
>>> +Non-volatile DIMMs are memory modules used to provide (cacheable) main memory
>>
>> Are DIMMs always going to be the only form factor for NV memory?
>>
>> And if you have multiple DIMMs, does each DT node correspond to a DIMM?
>
> A nvdimm-region might correspond to a single NVDIMM, a set of
> interleaved NVDIMMs, or it might just be a chunk of normal memory that
> you want treated as a NVDIMM for some reason. The last case is useful
> for provisioning install media on servers since it allows you do
> download a DVD image, turn it into an nvdimm-region, and kexec into
> the installer which can use it as a root disk. That may seem a little
> esoteric, but it's handy and we're using a full linux environment for
> our boot loader so it's easy to make use of.
I'm really just asking if we should drop the "dimm" name because it is
not always a DIMM. Maybe pmem instead? I don't know, naming is
hard(TM).
>> If not, then what if we want/need to provide power control to a DIMM?
>
> That would require a DIMM (and probably memory controller) specific
> driver. I've deliberately left out how regions are mapped back to
> DIMMs from the binding since it's not really clear to me how that
> should work. A phandle array pointing to each DIMM device (which could
> be anything) would do the trick, but I've found that a bit awkward to
> plumb into the model that libnvdimm expects.
>
>>> +that retains its contents across power cycles. In more practical terms, they
>>> +are kind of storage device where the contents can be accessed by the CPU
>>> +directly, rather than indirectly via a storage controller or similar. The an
>>> +nvdimm-region specifies a physical address range that is hosted on an NVDIMM
>>> +device.
>>> +
>>> +Bindings for the region nodes:
>>> +-----------------------------
>>> +
>>> +Required properties:
>>> + - compatible = "nvdimm-region"
>>> +
>>> + - reg = <base, size>;
>>> + The system physical address range of this nvdimm region.
>>> +
>>> +Optional properties:
>>> + - Any relevant NUMA assocativity properties for the target platform.
>>> + - A "volatile" property indicating that this region is actually in
>>> + normal DRAM and does not require cache flushes after each write.
>>> +
>>> +A complete example:
>>> +--------------------
>>> +
>>> +/ {
>>> + #size-cells = <2>;
>>> + #address-cells = <2>;
>>> +
>>> + platform {
>>
>> Perhaps we need a more well defined node here. Like we have 'memory' for
>> memory nodes.
>
> I think treating it as a platform device is fine. Memory nodes are
Platform device is a Linux term...
> special since the OS needs to know where it can allocate early in boot
> and I don't see non-volatile memory as being similarly significant.
> Fundamentally an NVDIMM is just a memory mapped storage device so we
> should be able to defer looking at them until later in boot.
It's not clear if 'platform' is just an example or random name or what
the node is required to be called. In the latter case, we should be
much more specific because 'platform' could be anything. In the former
case, then we have no way to find or validate the node because the
name could be anything and there's no compatible property either.
"region" is pretty generic too.
>
> That said you might have problems with XIP kernels and what not. I
> think that problem is better solved through other means though.
>
>>> + region@5000 {
>>> + compatible = "nvdimm-region;
>>> + reg = <0x00000001 0x00000000 0x00000000 0x40000000>
>>> +
>>> + };
>>> +
>>> + region@6000 {
>>> + compatible = "nvdimm-region";
>>> + reg = <0x00000001 0x00000000 0x00000000 0x40000000>
Thinking about this some more, the 2 levels of nodes is pointless.
Just follow memory nodes structure.
nv-memory@100000000 {
compatible = "nvdimm-region";
reg = <0x00000001 0x00000000 0x00000000 0x40000000>;
};
nv-memory@200000000 {
compatible = "nvdimm-region";
reg = <0x00000002 0x00000000 0x00000000 0x40000000>;
};
or:
nv-memory@100000000 {
compatible = "nvdimm-region";
reg = <0x00000001 0x00000000 0x00000000 0x40000000>
<0x00000002 0x00000000 0x00000000 0x40000000>;
};
Both forms should be allowed.
Rob
^ permalink raw reply
* Re: [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL
From: Vasant Hegde @ 2018-03-28 17:09 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linuxppc-dev, Stewart Smith, Mahesh Jagannath Salgaonkar,
Ananth N Mavinakayanahalli
In-Reply-To: <20180327172856.252ec56b@roar.ozlabs.ibm.com>
On 03/27/2018 12:58 PM, Nicholas Piggin wrote:
> On Tue, 27 Mar 2018 12:42:32 +0530
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> 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 use OPAL_DEBUG to
>>> print the opal stack and return the Linux stack, which can then be
>>> dumped by xmon
>>
>> Nick,
>>
>>
>> OPAL uses FSP/cronus interface for many of debug interface (like OPAL assert,
>> getting opal console, triggering FSP R/R etc). May be in future we may add new
>> debug capability.
>
> It would be good to ensure an API could accommodate them, or at least
> not get in the way.
Agree.
>
>> Once secureboot is enabled none of these interface work and we have limited debug
>> capability.
>>
>> Here you are using very generic API name (OPAL_DEBUG). May be we should have generic
>> interface (exported via debugfs?) here rather than SRESET specific one.
>
> OPAL_DEBUG here actually uses the sub-function OPAL_DEBUG_DUMP_STACK (1),
> but I didn't bring that constant across from skiboot which I should have.
Nick,
May be we should define sub-function usage. Also current API limits number of
arguments
and its type. may be we should have argument 2 as "void *" ?
something like :
s64 opal_debug(u32 debug_type, void *data, u64 dsize);
That way individual sub-function can parse/use based on its need.
>
> But I don't think this is SRESET specific. If Linux has any way to get
> an r1 for a CPU in OPAL, then it can use this function. If it does not,
> then it simply can't use it.
>
> I haven't really followed what's happening with secure boot, but presumably
> we can still get NMIs (at least machine check, even if all system reset
> sources are suppressed).
AFAIK secureboot won't block us here. It mostly blocks external entity (like
FSP/cronus) from
accessing host memory. (like they can't directly read, write to host memory,
SCOM operations
are restricted etc).
-Vasant
^ permalink raw reply
* Re: [PATCH v9 08/24] mm: Protect VMA modifications using VMA sequence count
From: Laurent Dufour @ 2018-03-28 17:10 UTC (permalink / raw)
To: David Rientjes
Cc: paulmck, peterz, Andrew Morton, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <alpine.DEB.2.20.1803271454390.41987@chino.kir.corp.google.com>
On 27/03/2018 23:57, David Rientjes wrote:
> 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_start) {
>> - vma->vm_start = start;
>> + WRITE_ONCE(vma->vm_start, start);
>> start_changed = true;
>> }
>> if (end != vma->vm_end) {
>> - vma->vm_end = end;
>> + WRITE_ONCE(vma->vm_end, end);
>> end_changed = true;
>> }
>> - vma->vm_pgoff = pgoff;
>> + WRITE_ONCE(vma->vm_pgoff, pgoff);
>> if (adjust_next) {
>> - next->vm_start += adjust_next << PAGE_SHIFT;
>> - next->vm_pgoff += adjust_next;
>> + WRITE_ONCE(next->vm_start,
>> + next->vm_start + (adjust_next << PAGE_SHIFT));
>> + WRITE_ONCE(next->vm_pgoff, next->vm_pgoff + adjust_next);
>> }
>>
>> if (root) {
>> @@ -1781,6 +1782,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
>> out:
>> perf_event_mmap(vma);
>>
>> + vm_write_begin(vma);
>> vm_stat_account(mm, vm_flags, len >> PAGE_SHIFT);
>> if (vm_flags & VM_LOCKED) {
>> if (!((vm_flags & VM_SPECIAL) || is_vm_hugetlb_page(vma) ||
>> @@ -1803,6 +1805,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
>> vma->vm_flags |= VM_SOFTDIRTY;
>>
>> vma_set_page_prot(vma);
>> + vm_write_end(vma);
>>
>> return addr;
>>
>
> Shouldn't this also protect vma->vm_flags?
Nice catch !
I just found that too while reviewing the entire patch to answer your previous
email.
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1796,7 +1796,8 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> vma == get_gate_vma(current->mm)))
> mm->locked_vm += (len >> PAGE_SHIFT);
> else
> - vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> + WRITE_ONCE(vma->vm_flags,
> + vma->vm_flags & VM_LOCKED_CLEAR_MASK);
> }
>
> if (file)
> @@ -1809,7 +1810,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> * then new mapped in-place (which must be aimed as
> * a completely new data area).
> */
> - vma->vm_flags |= VM_SOFTDIRTY;
> + WRITE_ONCE(vma->vm_flags, vma->vm_flags | VM_SOFTDIRTY);
>
> vma_set_page_prot(vma);
> vm_write_end(vma);
>
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors
From: Vasant Hegde @ 2018-03-28 17:17 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, skiboot
In-Reply-To: <20180327173857.0d195b66@roar.ozlabs.ibm.com>
On 03/27/2018 01:08 PM, Nicholas Piggin wrote:
> On Tue, 27 Mar 2018 12:47:31 +0530
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> 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-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/platforms/powernv/opal-nvram.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/powerpc/platforms/powernv/opal-nvram.c b/arch/powerpc/platforms/powernv/opal-nvram.c
>>> index 9db4398ded5d..13bf625dc3e8 100644
>>> --- a/arch/powerpc/platforms/powernv/opal-nvram.c
>>> +++ b/arch/powerpc/platforms/powernv/opal-nvram.c
>>> @@ -59,6 +59,8 @@ static ssize_t opal_nvram_write(char *buf, size_t count, loff_t *index)
>>> if (rc == OPAL_BUSY_EVENT)
>>> opal_poll_events(NULL);
>>
>> Current code does continuous poller here. May be we have small breathing time
>> here. What you say?
>
> Yeah that's probably not a bad idea. I cc'ed skiboot list -- what's a
> reasonable delay between retries?
I think it depends on individual API. Like in case of dump retrival I've 20ms
delay... as FSP takes time to copy data to host memory. But may be here we can
have smaller delay.
> Linux has a bunch of similar kind of
> loops if you grep for opal_poll_events and OPAL_BUSY. It would be good
> to convert them all to a standard form with a standard delay as
> recommended by OPAL, and where specific calls have different delay
> for a good reason, that would be documented in the OPAL API docs.
Yes. We should update API documentation.
-Vasant
^ permalink raw reply
* Re: [PATCH 6/6] doc/devicetree: NVDIMM region documentation
From: Dan Williams @ 2018-03-28 17:25 UTC (permalink / raw)
To: Rob Herring; +Cc: Oliver, linux-nvdimm@lists.01.org, Device Tree, linuxppc-dev
In-Reply-To: <CAL_Jsq+jC2mAXbKh9c8dbLXZmWbD-sFemrk+8p-oGMkXqSMfnQ@mail.gmail.com>
On Wed, Mar 28, 2018 at 10:06 AM, Rob Herring <robh@kernel.org> wrote:
[..]
> >> Are DIMMs always going to be the only form factor for NV memory?
> >>
> >> And if you have multiple DIMMs, does each DT node correspond to a DIMM?
> >
> > A nvdimm-region might correspond to a single NVDIMM, a set of
> > interleaved NVDIMMs, or it might just be a chunk of normal memory that
> > you want treated as a NVDIMM for some reason. The last case is useful
> > for provisioning install media on servers since it allows you do
> > download a DVD image, turn it into an nvdimm-region, and kexec into
> > the installer which can use it as a root disk. That may seem a little
> > esoteric, but it's handy and we're using a full linux environment for
> > our boot loader so it's easy to make use of.
>
> I'm really just asking if we should drop the "dimm" name because it is
> not always a DIMM. Maybe pmem instead? I don't know, naming is
> hard(TM).
The Linux enabling uses the term "memory device". The Linux device
object name for memory devices is "nmem".
[..]
> > special since the OS needs to know where it can allocate early in boot
> > and I don't see non-volatile memory as being similarly significant.
> > Fundamentally an NVDIMM is just a memory mapped storage device so we
> > should be able to defer looking at them until later in boot.
>
> It's not clear if 'platform' is just an example or random name or what
> the node is required to be called. In the latter case, we should be
> much more specific because 'platform' could be anything. In the former
> case, then we have no way to find or validate the node because the
> name could be anything and there's no compatible property either.
>
> "region" is pretty generic too.
>
The term "nvdimm-region" has specific meaning to the libnvdimm
sub-system. It is a contiguous physical address range backed by one or
more memory devices, DIMMs, in an interleaved configuration
(interleave set).
One feature that is currently missing from libnvdimm is a management
interface to change an interleave configuration. To date, Linux only
reads a static region configuration published by platform firmware.
Linux can provide dynamic provisioning of namespaces out of those
regions, but interleave configuration has been left to vendor specific
tooling to date. It would be great to start incorporating generic
Linux support for that capability across platform firmware
implementations.
^ permalink raw reply
* Re: [PATCH v9 07/24] mm: VMA sequence count
From: Laurent Dufour @ 2018-03-28 17:58 UTC (permalink / raw)
To: David Rientjes
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <alpine.DEB.2.20.1803271429230.36401@chino.kir.corp.google.com>
On 27/03/2018 23:30, David Rientjes wrote:
> 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_end = vm_end_gap(vma);
>>
>> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>> + seqcount_init(&vma->vm_sequence);
>> +#endif
>> +
>> /*
>> * vma->vm_prev wasn't known when we followed the rbtree to find the
>> * correct insertion point for that vma. As a result, we could not
>> @@ -692,6 +696,30 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> long adjust_next = 0;
>> int remove_next = 0;
>>
>> + /*
>> + * Why using vm_raw_write*() functions here to avoid lockdep's warning ?
>> + *
>> + * Locked is complaining about a theoretical lock dependency, involving
>> + * 3 locks:
>> + * mapping->i_mmap_rwsem --> vma->vm_sequence --> fs_reclaim
>> + *
>> + * Here are the major path leading to this dependency :
>> + * 1. __vma_adjust() mmap_sem -> vm_sequence -> i_mmap_rwsem
>> + * 2. move_vmap() mmap_sem -> vm_sequence -> fs_reclaim
>> + * 3. __alloc_pages_nodemask() fs_reclaim -> i_mmap_rwsem
>> + * 4. unmap_mapping_range() i_mmap_rwsem -> vm_sequence
>> + *
>> + * So there is no way to solve this easily, especially because in
>> + * unmap_mapping_range() the i_mmap_rwsem is grab while the impacted
>> + * VMAs are not yet known.
>> + * However, the way the vm_seq is used is guarantying that we will
>> + * never block on it since we just check for its value and never wait
>> + * for it to move, see vma_has_changed() and handle_speculative_fault().
>> + */
>> + vm_raw_write_begin(vma);
>> + if (next)
>> + vm_raw_write_begin(next);
>> +
>> if (next && !insert) {
>> struct vm_area_struct *exporter = NULL, *importer = NULL;
>>
>
> Eek, what about later on:
>
> /*
> * Easily overlooked: when mprotect shifts the boundary,
> * make sure the expanding vma has anon_vma set if the
> * shrinking vma had, to cover any anon pages imported.
> */
> if (exporter && exporter->anon_vma && !importer->anon_vma) {
> int error;
>
> importer->anon_vma = exporter->anon_vma;
> error = anon_vma_clone(importer, exporter);
> if (error)
> return error;
> }
>
> This needs
>
> if (error) {
> if (next && next != vma)
> vm_raw_write_end(next);
> vm_raw_write_end(vma);
> return error;
> }
Nice catch !
Thanks,
Laurent.
^ permalink raw reply
* Re: [PATCH v9 09/24] mm: protect mremap() against SPF hanlder
From: Laurent Dufour @ 2018-03-28 18:11 UTC (permalink / raw)
To: David Rientjes
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <alpine.DEB.2.20.1803271500540.43106@chino.kir.corp.google.com>
On 28/03/2018 00:12, David Rientjes wrote:
> 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 int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin);
>> extern int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert,
>> - struct vm_area_struct *expand);
>> + struct vm_area_struct *expand, bool keep_locked);
>> static inline int vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert)
>> {
>> - return __vma_adjust(vma, start, end, pgoff, insert, NULL);
>> + return __vma_adjust(vma, start, end, pgoff, insert, NULL, false);
>> }
>> -extern struct vm_area_struct *vma_merge(struct mm_struct *,
>> +extern struct vm_area_struct *__vma_merge(struct mm_struct *,
>> struct vm_area_struct *prev, unsigned long addr, unsigned long end,
>> unsigned long vm_flags, struct anon_vma *, struct file *, pgoff_t,
>> - struct mempolicy *, struct vm_userfaultfd_ctx);
>> + struct mempolicy *, struct vm_userfaultfd_ctx, bool keep_locked);
>> +static inline struct vm_area_struct *vma_merge(struct mm_struct *vma,
>> + struct vm_area_struct *prev, unsigned long addr, unsigned long end,
>> + unsigned long vm_flags, struct anon_vma *anon, struct file *file,
>> + pgoff_t off, struct mempolicy *pol, struct vm_userfaultfd_ctx uff)
>> +{
>> + return __vma_merge(vma, prev, addr, end, vm_flags, anon, file, off,
>> + pol, uff, false);
>> +}
>
> The first formal to vma_merge() is an mm, not a vma.
Oops !
> This area could use an uncluttering.
>
>> extern struct anon_vma *find_mergeable_anon_vma(struct vm_area_struct *);
>> extern int __split_vma(struct mm_struct *, struct vm_area_struct *,
>> unsigned long addr, int new_below);
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index d6533cb85213..ac32b577a0c9 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -684,7 +684,7 @@ static inline void __vma_unlink_prev(struct mm_struct *mm,
>> */
>> int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert,
>> - struct vm_area_struct *expand)
>> + struct vm_area_struct *expand, bool keep_locked)
>> {
>> struct mm_struct *mm = vma->vm_mm;
>> struct vm_area_struct *next = vma->vm_next, *orig_vma = vma;
>> @@ -996,7 +996,8 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>>
>> if (next && next != vma)
>> vm_raw_write_end(next);
>> - vm_raw_write_end(vma);
>> + if (!keep_locked)
>> + vm_raw_write_end(vma);
>>
>> validate_mm(mm);
>>
>
> This will require a fixup for the following patch where a retval from
> anon_vma_close() can also return without vma locked even though
> keep_locked == true.
Yes I saw your previous email about that.
>
> How does vma_merge() handle that error wrt vm_raw_write_begin(vma)?
The not written assumption is that in the case __vma_adjust() is returning an
error, the vma is no more sequence locked. That's need to be clarify a huge
comment near the __vma_adjust() definition.
This being said, in that case of __vma_merge() is returning NULL which means
that it didn't do the job (the caller don't know if this is due to an error or
because the VMA cannot be merged). In that case again the assumption is that
the VMA are no locked in that case since the merge operation was not done. But
again this is not documented at all and I've to fix that.
In addition the caller copy_vma() which is the only one calling __vma_merge()
with keep_locked=true, is assuming that in that case, the VMA is not locked and
it will allocate a new VMA which will be locked before it is inserted in the RB
tree.
So it should work, but I've to make a huge effort to document that in the code.
Thanks a lot for raising this !
>
>> @@ -1132,12 +1133,13 @@ can_vma_merge_after(struct vm_area_struct *vma, unsigned long vm_flags,
>> * parameter) may establish ptes with the wrong permissions of NNNN
>> * instead of the right permissions of XXXX.
>> */
>> -struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> +struct vm_area_struct *__vma_merge(struct mm_struct *mm,
>> struct vm_area_struct *prev, unsigned long addr,
>> unsigned long end, unsigned long vm_flags,
>> struct anon_vma *anon_vma, struct file *file,
>> pgoff_t pgoff, struct mempolicy *policy,
>> - struct vm_userfaultfd_ctx vm_userfaultfd_ctx)
>> + struct vm_userfaultfd_ctx vm_userfaultfd_ctx,
>> + bool keep_locked)
>> {
>> pgoff_t pglen = (end - addr) >> PAGE_SHIFT;
>> struct vm_area_struct *area, *next;
>> @@ -1185,10 +1187,11 @@ struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> /* cases 1, 6 */
>> err = __vma_adjust(prev, prev->vm_start,
>> next->vm_end, prev->vm_pgoff, NULL,
>> - prev);
>> + prev, keep_locked);
>> } else /* cases 2, 5, 7 */
>> err = __vma_adjust(prev, prev->vm_start,
>> - end, prev->vm_pgoff, NULL, prev);
>> + end, prev->vm_pgoff, NULL, prev,
>> + keep_locked);
>> if (err)
>> return NULL;
>> khugepaged_enter_vma_merge(prev, vm_flags);
>> @@ -1205,10 +1208,12 @@ struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> vm_userfaultfd_ctx)) {
>> if (prev && addr < prev->vm_end) /* case 4 */
>> err = __vma_adjust(prev, prev->vm_start,
>> - addr, prev->vm_pgoff, NULL, next);
>> + addr, prev->vm_pgoff, NULL, next,
>> + keep_locked);
>> else { /* cases 3, 8 */
>> err = __vma_adjust(area, addr, next->vm_end,
>> - next->vm_pgoff - pglen, NULL, next);
>> + next->vm_pgoff - pglen, NULL, next,
>> + keep_locked);
>> /*
>> * In case 3 area is already equal to next and
>> * this is a noop, but in case 8 "area" has
>> @@ -3163,9 +3168,20 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
>>
>> if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent))
>> return NULL; /* should never get here */
>> - new_vma = vma_merge(mm, prev, addr, addr + len, vma->vm_flags,
>> - vma->anon_vma, vma->vm_file, pgoff, vma_policy(vma),
>> - vma->vm_userfaultfd_ctx);
>> +
>> + /* There is 3 cases to manage here in
>> + * AAAA AAAA AAAA AAAA
>> + * PPPP.... PPPP......NNNN PPPP....NNNN PP........NN
>> + * PPPPPPPP(A) PPPP..NNNNNNNN(B) PPPPPPPPPPPP(1) NULL
>> + * PPPPPPPPNNNN(2)
>> + * PPPPNNNNNNNN(3)
>> + *
>> + * new_vma == prev in case A,1,2
>> + * new_vma == next in case B,3
>> + */
>
> Interleaved tabs and whitespace.
Fair enough, I will try to fix that.
>> + new_vma = __vma_merge(mm, prev, addr, addr + len, vma->vm_flags,
>> + vma->anon_vma, vma->vm_file, pgoff,
>> + vma_policy(vma), vma->vm_userfaultfd_ctx, true);
>> if (new_vma) {
>> /*
>> * Source vma may have been merged into new_vma
>> @@ -3205,6 +3221,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
>> get_file(new_vma->vm_file);
>> if (new_vma->vm_ops && new_vma->vm_ops->open)
>> new_vma->vm_ops->open(new_vma);
>> + /*
>> + * As the VMA is linked right now, it may be hit by the
>> + * speculative page fault handler. But we don't want it to
>> + * to start mapping page in this area until the caller has
>> + * potentially move the pte from the moved VMA. To prevent
>> + * that we protect it right now, and let the caller unprotect
>> + * it once the move is done.
>> + */
>> + vm_raw_write_begin(new_vma);
>> vma_link(mm, new_vma, prev, rb_link, rb_parent);
>> *need_rmap_locks = false;
>> }
>> diff --git a/mm/mremap.c b/mm/mremap.c
>> index 049470aa1e3e..8ed1a1d6eaed 100644
>> --- a/mm/mremap.c
>> +++ b/mm/mremap.c
>> @@ -302,6 +302,14 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>> if (!new_vma)
>> return -ENOMEM;
>>
>> + /* new_vma is returned protected by copy_vma, to prevent speculative
>> + * page fault to be done in the destination area before we move the pte.
>> + * Now, we must also protect the source VMA since we don't want pages
>> + * to be mapped in our back while we are copying the PTEs.
>> + */
>> + if (vma != new_vma)
>> + vm_raw_write_begin(vma);
>> +
>> moved_len = move_page_tables(vma, old_addr, new_vma, new_addr, old_len,
>> need_rmap_locks);
>> if (moved_len < old_len) {
>> @@ -318,6 +326,8 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>> */
>> move_page_tables(new_vma, new_addr, vma, old_addr, moved_len,
>> true);
>> + if (vma != new_vma)
>> + vm_raw_write_end(vma);
>> vma = new_vma;
>> old_len = new_len;
>> old_addr = new_addr;
>> @@ -326,7 +336,10 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>> mremap_userfaultfd_prep(new_vma, uf);
>> arch_remap(mm, old_addr, old_addr + old_len,
>> new_addr, new_addr + new_len);
>> + if (vma != new_vma)
>> + vm_raw_write_end(vma);
>> }
>> + vm_raw_write_end(new_vma);
>
> Just do
>
> vm_raw_write_end(vma);
> vm_raw_write_end(new_vma);
>
> here.
Are you sure ? we can have vma = new_vma done if (unlikely(err))
Cheers,
Laurent.
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper, punit.agrawal,
aneesh.kumar, npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Andrea Arcangeli, Oleg Nesterov, linux-alpha, LKML,
linux-snps-arc, linux-ia64, linux-metag, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, Linux-MM
In-Reply-To: <20180327143820.GH5652@dhcp22.suse.cz>
> On 27 Mar 2018, at 17:38, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>=20
>>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>=20
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>=20
>>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>=20
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>=20
>>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>>>>>=20
>>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by =
mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the =
process
>>>>>>>> creation. After that mmap build very predictable layout of =
address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>=20
>>>>>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>>>>>> capable of specifying random numbers in the first argument of =
mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not =
possible IMO;
>>>>>=20
>>>>> Is this really so helpful?
>>>>=20
>>>> Yes, ASLR is one of very important mitigation techniques which are =
really used=20
>>>> to protect applications. If there is no ASLR, it is very easy to =
exploit=20
>>>> vulnerable application and compromise the system. We can=E2=80=99t =
just fix all the=20
>>>> vulnerabilities right now, thats why we have mitigations - =
techniques which are=20
>>>> makes exploitation more hard or impossible in some cases.
>>>>=20
>>>> Thats why it is helpful.
>>>=20
>>> I am not questioning ASLR in general. I am asking whether we really =
need
>>> per mmap ASLR in general. I can imagine that some environments want =
to
>>> pay the additional price and other side effects, but considering =
this
>>> can be achieved by libc, why to add more code to the kernel?
>>=20
>> I believe this is the only one right place for it. Adding these 200+ =
lines of=20
>> code we give this feature for any user - on desktop, on server, on =
IoT device,=20
>> on SCADA, etc. But if only glibc will implement =E2=80=98user-mode-aslr=
=E2=80=99 IoT and SCADA=20
>> devices will never get it.
>=20
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>=20
There are following reasons:
1) To protect layout if one region was leaked (as you said).=20
2) To protect against exploitation of Out-of-bounds vulnerabilities in =
some=20
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases =
(CWE-120)
4) To protect application in cases when attacker need to guess the =
address=20
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but =
a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to =
prevent=20
exploitation but not to fix vulnerabilities. It means good mitigation =
will make=20
vulnerable application crash but not been compromised in most cases. =
This means=20
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply
* [PATCH v2] powerpc/altivec: Add missing prototypes for altivec
From: Mathieu Malaterre @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, Matt Brown, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-15-malat@debian.org>
Some functions prototypes were missing for the non-altivec code. Add the
missing prototypes in a new header file, fix warnings treated as errors
with W=1:
arch/powerpc/lib/xor_vmx_glue.c:18:6: error: no previous prototype for ‘xor_altivec_2’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_vmx_glue.c:29:6: error: no previous prototype for ‘xor_altivec_3’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_vmx_glue.c:40:6: error: no previous prototype for ‘xor_altivec_4’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_vmx_glue.c:52:6: error: no previous prototype for ‘xor_altivec_5’ [-Werror=missing-prototypes]
The prototypes were already present in <asm/xor.h> but this header file is
meant to be included after <include/linux/raid/xor.h>. Trying to re-use
<asm/xor.h> directly would lead to warnings such as:
arch/powerpc/include/asm/xor.h:39:15: error: variable ‘xor_block_altivec’ has initializer but incomplete type
Trying to re-use <asm/xor.h> after <include/linux/raid/xor.h> in
xor_vmx_glue.c would in turn trigger the following warnings:
include/asm-generic/xor.h:688:34: error: ‘xor_block_32regs’ defined but not used [-Werror=unused-variable]
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/powerpc/include/asm/xor.h | 12 +-----------
arch/powerpc/include/asm/xor_altivec.h | 19 +++++++++++++++++++
arch/powerpc/lib/xor_vmx_glue.c | 1 +
3 files changed, 21 insertions(+), 11 deletions(-)
create mode 100644 arch/powerpc/include/asm/xor_altivec.h
diff --git a/arch/powerpc/include/asm/xor.h b/arch/powerpc/include/asm/xor.h
index a36c2069d8ed..7d6dc503349d 100644
--- a/arch/powerpc/include/asm/xor.h
+++ b/arch/powerpc/include/asm/xor.h
@@ -24,17 +24,7 @@
#include <asm/cputable.h>
#include <asm/cpu_has_feature.h>
-
-void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in);
-void xor_altivec_3(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in, unsigned long *v3_in);
-void xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in, unsigned long *v3_in,
- unsigned long *v4_in);
-void xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in, unsigned long *v3_in,
- unsigned long *v4_in, unsigned long *v5_in);
+#include <asm/xor_altivec.h>
static struct xor_block_template xor_block_altivec = {
.name = "altivec",
diff --git a/arch/powerpc/include/asm/xor_altivec.h b/arch/powerpc/include/asm/xor_altivec.h
new file mode 100644
index 000000000000..6ca923510b59
--- /dev/null
+++ b/arch/powerpc/include/asm/xor_altivec.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_POWERPC_XOR_ALTIVEC_H
+#define _ASM_POWERPC_XOR_ALTIVEC_H
+
+#ifdef CONFIG_ALTIVEC
+
+void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in);
+void xor_altivec_3(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in, unsigned long *v3_in);
+void xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in, unsigned long *v3_in,
+ unsigned long *v4_in);
+void xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in, unsigned long *v3_in,
+ unsigned long *v4_in, unsigned long *v5_in);
+
+#endif
+#endif /* _ASM_POWERPC_XOR_ALTIVEC_H */
diff --git a/arch/powerpc/lib/xor_vmx_glue.c b/arch/powerpc/lib/xor_vmx_glue.c
index 6521fe5e8cef..dab2b6bfcf36 100644
--- a/arch/powerpc/lib/xor_vmx_glue.c
+++ b/arch/powerpc/lib/xor_vmx_glue.c
@@ -13,6 +13,7 @@
#include <linux/export.h>
#include <linux/sched.h>
#include <asm/switch_to.h>
+#include <asm/xor_altivec.h>
#include "xor_vmx.h"
void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
--
2.11.0
^ permalink raw reply related
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
In-Reply-To: <20180327221635.GA3790@thunk.org>
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>=20
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>=20
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a =
performance
>> issue.
>=20
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>=20
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking=E2=80=A6
>>=20
>> I think we need to know what libc developers will say on implementing =
ASLR in=20
>> user-mode. I am pretty sure they will say =E2=80=98nether=E2=80=99 or =
=E2=80=98some-day=E2=80=99. And problem=20
>> of ASLR will stay forever.
>=20
> Why can't you send patches to the libc developers?
>=20
> Regards,
>=20
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply
* [PATCH v3] powerpc/altivec: Add missing prototypes for altivec
From: Mathieu Malaterre @ 2018-03-28 18:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, Matt Brown, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-15-malat@debian.org>
Some functions prototypes were missing for the non-altivec code. Add the
missing prototypes in a new header file, fix warnings treated as errors
with W=1:
arch/powerpc/lib/xor_vmx_glue.c:18:6: error: no previous prototype for ‘xor_altivec_2’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_vmx_glue.c:29:6: error: no previous prototype for ‘xor_altivec_3’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_vmx_glue.c:40:6: error: no previous prototype for ‘xor_altivec_4’ [-Werror=missing-prototypes]
arch/powerpc/lib/xor_vmx_glue.c:52:6: error: no previous prototype for ‘xor_altivec_5’ [-Werror=missing-prototypes]
The prototypes were already present in <asm/xor.h> but this header file is
meant to be included after <include/linux/raid/xor.h>. Trying to re-use
<asm/xor.h> directly would lead to warnings such as:
arch/powerpc/include/asm/xor.h:39:15: error: variable ‘xor_block_altivec’ has initializer but incomplete type
Trying to re-use <asm/xor.h> after <include/linux/raid/xor.h> in
xor_vmx_glue.c would in turn trigger the following warnings:
include/asm-generic/xor.h:688:34: error: ‘xor_block_32regs’ defined but not used [-Werror=unused-variable]
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v3: missing changelog, no other change
v2: new version where a separate header was introduced. Also update commit message explaining history.
arch/powerpc/include/asm/xor.h | 12 +-----------
arch/powerpc/include/asm/xor_altivec.h | 19 +++++++++++++++++++
arch/powerpc/lib/xor_vmx_glue.c | 1 +
3 files changed, 21 insertions(+), 11 deletions(-)
create mode 100644 arch/powerpc/include/asm/xor_altivec.h
diff --git a/arch/powerpc/include/asm/xor.h b/arch/powerpc/include/asm/xor.h
index a36c2069d8ed..7d6dc503349d 100644
--- a/arch/powerpc/include/asm/xor.h
+++ b/arch/powerpc/include/asm/xor.h
@@ -24,17 +24,7 @@
#include <asm/cputable.h>
#include <asm/cpu_has_feature.h>
-
-void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in);
-void xor_altivec_3(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in, unsigned long *v3_in);
-void xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in, unsigned long *v3_in,
- unsigned long *v4_in);
-void xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
- unsigned long *v2_in, unsigned long *v3_in,
- unsigned long *v4_in, unsigned long *v5_in);
+#include <asm/xor_altivec.h>
static struct xor_block_template xor_block_altivec = {
.name = "altivec",
diff --git a/arch/powerpc/include/asm/xor_altivec.h b/arch/powerpc/include/asm/xor_altivec.h
new file mode 100644
index 000000000000..6ca923510b59
--- /dev/null
+++ b/arch/powerpc/include/asm/xor_altivec.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_POWERPC_XOR_ALTIVEC_H
+#define _ASM_POWERPC_XOR_ALTIVEC_H
+
+#ifdef CONFIG_ALTIVEC
+
+void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in);
+void xor_altivec_3(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in, unsigned long *v3_in);
+void xor_altivec_4(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in, unsigned long *v3_in,
+ unsigned long *v4_in);
+void xor_altivec_5(unsigned long bytes, unsigned long *v1_in,
+ unsigned long *v2_in, unsigned long *v3_in,
+ unsigned long *v4_in, unsigned long *v5_in);
+
+#endif
+#endif /* _ASM_POWERPC_XOR_ALTIVEC_H */
diff --git a/arch/powerpc/lib/xor_vmx_glue.c b/arch/powerpc/lib/xor_vmx_glue.c
index 6521fe5e8cef..dab2b6bfcf36 100644
--- a/arch/powerpc/lib/xor_vmx_glue.c
+++ b/arch/powerpc/lib/xor_vmx_glue.c
@@ -13,6 +13,7 @@
#include <linux/export.h>
#include <linux/sched.h>
#include <asm/switch_to.h>
+#include <asm/xor_altivec.h>
#include "xor_vmx.h"
void xor_altivec_2(unsigned long bytes, unsigned long *v1_in,
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Rob Landley @ 2018-03-28 19:04 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Shea Levy, linux-riscv, linux-kernel, Christoph Hellwig,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Catalin Marinas, Will Deacon, Mark Salter, Aurelien Jacquiot,
Mikael Starvik, Jesper Nilsson, Yoshinori Sato, Richard Kuo,
Tony Luck, Fenghua Yu, Geert Uytterhoeven, James Hogan,
Michal Simek, Ralf Baechle, David Howells, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens, Chen Liqin, Lennox Wu,
Rich Felker, David S. Miller, Jeff Dike, Richard Weinberger,
Guan Xuetao, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Chris Zankel, Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches,
Oliver O'Halloran, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, linux-alpha, linux-snps-arc,
linux-arm-kernel, adi-buildroot-devel, linux-c6x-dev,
linux-cris-kernel, uclinux-h8-devel, linux-hexagon, linux-ia64,
linux-m68k, linux-metag, linux-mips, linux-am33-list, nios2-dev,
openrisc, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa
In-Reply-To: <20180328164813.GA3888@n2100.armlinux.org.uk>
On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>> Now only those architectures that have custom initrd free requirements
>>> need to define free_initrd_mem.
>> ...
>>> --- a/arch/arc/mm/init.c
>>> +++ b/arch/arc/mm/init.c
>>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>>> {
>>> free_initmem_default(-1);
>>> }
>>> -
>>> -#ifdef CONFIG_BLK_DEV_INITRD
>>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>>> -{
>>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>> -}
>>> -#endif
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 3f972e83909b..19d1c5594e2d 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -47,6 +47,7 @@ config ARM
>>> select HARDIRQS_SW_RESEND
>>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>>> + select HAVE_ARCH_FREE_INITRD_MEM
>>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>>> select HAVE_ARCH_MMAP_RND_BITS if MMU
>>
>> Isn't this why weak symbols were invented?
>
> Weak symbols means that we end up with both the weakly-referenced code
> and the arch code in the kernel image. That's fine if the weak code
> is small.
The kernel's been able to build with link time garbage collection since 2016:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
Wouldn't that remove the unused one?
Rob
^ permalink raw reply
* Re: [PATCH 11/19] powerpc/powermac: Move pmac_pfunc_base_install prototype to header file
From: Mathieu Malaterre @ 2018-03-28 19:11 UTC (permalink / raw)
To: christophe leroy; +Cc: Michael Ellerman, LKML, Paul Mackerras, linuxppc-dev
In-Reply-To: <fd5993b4-0b0a-3c65-65a8-b26445d0d440@c-s.fr>
On Fri, Mar 23, 2018 at 1:13 PM, christophe leroy
<christophe.leroy@c-s.fr> wrote:
>
>
> Le 22/03/2018 =C3=A0 21:19, Mathieu Malaterre a =C3=A9crit :
>>
>> The pmac_pfunc_base_install prototype was declared in powermac/smp.c sin=
ce
>> function was used there, move it to pmac_pfunc.h header to be visible in
>> pfunc_base.c. Fix a warning treated as error with W=3D1:
>>
>> arch/powerpc/platforms/powermac/pfunc_base.c:330:12: error: no previo=
us
>> prototype for =E2=80=98pmac_pfunc_base_install=E2=80=99 [-Werror=3Dmissi=
ng-prototypes]
>>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> arch/powerpc/include/asm/pmac_pfunc.h | 1 +
>> arch/powerpc/platforms/powermac/smp.c | 1 -
>> 2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/pmac_pfunc.h
>> b/arch/powerpc/include/asm/pmac_pfunc.h
>> index 73bd8f28f2a8..99f7a288789a 100644
>> --- a/arch/powerpc/include/asm/pmac_pfunc.h
>> +++ b/arch/powerpc/include/asm/pmac_pfunc.h
>> @@ -245,6 +245,7 @@ extern void pmf_put_function(struct pmf_function
>> *func);
>> extern int pmf_call_one(struct pmf_function *func, struct pmf_args
>> *args);
>> +extern int pmac_pfunc_base_install(void);
>
>
>
> extern keyword is not needed
I understand; but for consistency every single protoypes in this
header file actually use the extern keyword. Is there a guide/best
practice to refer to in this case ?
> Christophe
>
>> /* Suspend/resume code called by via-pmu directly for now */
>> extern void pmac_pfunc_base_suspend(void);
>> diff --git a/arch/powerpc/platforms/powermac/smp.c
>> b/arch/powerpc/platforms/powermac/smp.c
>> index 95275e0e2efa..447da6db450a 100644
>> --- a/arch/powerpc/platforms/powermac/smp.c
>> +++ b/arch/powerpc/platforms/powermac/smp.c
>> @@ -65,7 +65,6 @@
>> #endif
>> extern void __secondary_start_pmac_0(void);
>> -extern int pmac_pfunc_base_install(void);
>> static void (*pmac_tb_freeze)(int freeze);
>> static u64 timebase;
>>
>
> ---
> L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=
=C3=A9rifi=C3=A9e par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
^ permalink raw reply
* Re: [PATCH 15/19] powerpc: Add missing prototype
From: Mathieu Malaterre @ 2018-03-28 19:13 UTC (permalink / raw)
To: christophe leroy; +Cc: Michael Ellerman, LKML, Paul Mackerras, linuxppc-dev
In-Reply-To: <bd4be06c-b5f5-2516-1c1d-d2b6d7861090@c-s.fr>
On Fri, Mar 23, 2018 at 1:20 PM, christophe leroy
<christophe.leroy@c-s.fr> wrote:
>
>
> Le 22/03/2018 =C3=A0 21:20, Mathieu Malaterre a =C3=A9crit :
>>
>> Add one missing prototype for function rh_dump_blk. Fix warning treated =
as
>> error in W=3D1:
>>
>> arch/powerpc/lib/rheap.c:740:6: error: no previous prototype for
>> =E2=80=98rh_dump_blk=E2=80=99 [-Werror=3Dmissing-prototypes]
>>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> arch/powerpc/include/asm/rheap.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/rheap.h
>> b/arch/powerpc/include/asm/rheap.h
>> index 172381769cfc..e75d96de19a0 100644
>> --- a/arch/powerpc/include/asm/rheap.h
>> +++ b/arch/powerpc/include/asm/rheap.h
>> @@ -83,6 +83,9 @@ extern int rh_get_stats(rh_info_t * info, int what, in=
t
>> max_stats,
>> /* Simple dump of remote heap info */
>> extern void rh_dump(rh_info_t * info);
>> +/* Simple dump of remote info block */
>> +extern void rh_dump_blk(rh_info_t *info, rh_block_t *blk);
>> +
>
>
> Only used in one place, should be static
Well here is what I see over here:
$ git grep rh_dump_blk
...
arch/powerpc/lib/rheap.c:EXPORT_SYMBOL_GPL(rh_dump_blk);
> Christophe
>
>> /* Set owner of taken block */
>> extern int rh_set_owner(rh_info_t * info, unsigned long start, const
>> char *owner);
>>
>
>
> ---
> L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=
=C3=A9rifi=C3=A9e par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
^ permalink raw reply
* [PATCH v2 01/19] powerpc/powermac: Mark variable x as unused
From: Mathieu Malaterre @ 2018-03-28 19:27 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-2-malat@debian.org>
Since the value of x is never intended to be read, declare it with gcc
attribute as unused. Fix warning treated as error with W=1:
arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable]
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v2: move x variable within its local scope
arch/powerpc/platforms/powermac/bootx_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powermac/bootx_init.c b/arch/powerpc/platforms/powermac/bootx_init.c
index c3c9bbb3573a..d44e8571c1ec 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -468,7 +468,7 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
boot_infos_t *bi = (boot_infos_t *) r4;
unsigned long hdr;
unsigned long space;
- unsigned long ptr, x;
+ unsigned long ptr;
char *model;
unsigned long offset = reloc_offset();
@@ -562,6 +562,7 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
* MMU switched OFF, so this should not be useful anymore.
*/
if (bi->version < 4) {
+ unsigned long x __maybe_unused;
bootx_printf("Touching pages...\n");
/*
--
2.11.0
^ permalink raw reply related
* [PATCH v2 02/19] powerpc/powermac: Mark variable x as unused
From: Mathieu Malaterre @ 2018-03-28 19:30 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-3-malat@debian.org>
Since the value of x is never intended to be read, remove it. Fix warning
treated as error with W=1:
arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v2: remove x completely
arch/powerpc/platforms/powermac/udbg_scc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c b/arch/powerpc/platforms/powermac/udbg_scc.c
index d83135a9830e..8901973ed683 100644
--- a/arch/powerpc/platforms/powermac/udbg_scc.c
+++ b/arch/powerpc/platforms/powermac/udbg_scc.c
@@ -73,7 +73,7 @@ void udbg_scc_init(int force_scc)
struct device_node *stdout = NULL, *escc = NULL, *macio = NULL;
struct device_node *ch, *ch_def = NULL, *ch_a = NULL;
const char *path;
- int i, x;
+ int i;
escc = of_find_node_by_name(NULL, "escc");
if (escc == NULL)
@@ -120,7 +120,7 @@ void udbg_scc_init(int force_scc)
mb();
for (i = 20000; i != 0; --i)
- x = in_8(sccc);
+ in_8(sccc);
out_8(sccc, 0x09); /* reset A or B side */
out_8(sccc, 0xc0);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 03/19] powerpc: Mark variables as unused
From: Mathieu Malaterre @ 2018-03-28 19:33 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-4-malat@debian.org>
Add gcc attribute unused for two variables. Fix warnings treated as errors
with W=1:
arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v2: move path within ifdef DEBUG_PROM
arch/powerpc/kernel/prom_init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index acf4b2e0530c..4163b11abb6c 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -603,7 +603,7 @@ static void __init early_cmdline_parse(void)
const char *opt;
char *p;
- int l = 0;
+ int l __maybe_unused = 0;
prom_cmd_line[0] = 0;
p = prom_cmd_line;
@@ -1385,7 +1385,7 @@ static void __init reserve_mem(u64 base, u64 size)
static void __init prom_init_mem(void)
{
phandle node;
- char *path, type[64];
+ char *path __maybe_unused, type[64];
unsigned int plen;
cell_t *p, *endp;
__be32 val;
@@ -1406,7 +1406,6 @@ static void __init prom_init_mem(void)
prom_debug("root_size_cells: %x\n", rsc);
prom_debug("scanning memory:\n");
- path = prom_scratch;
for (node = 0; prom_next_node(&node); ) {
type[0] = 0;
@@ -1431,6 +1430,7 @@ static void __init prom_init_mem(void)
endp = p + (plen / sizeof(cell_t));
#ifdef DEBUG_PROM
+ path = prom_scratch;
memset(path, 0, PROM_SCRATCH_SIZE);
call_prom("package-to-path", 3, 1, node, path, PROM_SCRATCH_SIZE-1);
prom_debug(" node %s :\n", path);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 05/19] powerpc/chrp/setup: Add attribute unused and make some functions static
From: Mathieu Malaterre @ 2018-03-28 19:35 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-6-malat@debian.org>
Remove variable declaration idu_size and associated code since not used.
These functions can all be static, make it so. Fix warnings treated as
errors with W=1:
arch/powerpc/platforms/chrp/setup.c:97:6: error: no previous prototype for ‘chrp_show_cpuinfo’ [-Werror=missing-prototypes]
arch/powerpc/platforms/chrp/setup.c:302:13: error: no previous prototype for ‘chrp_setup_arch’ [-Werror=missing-prototypes]
arch/powerpc/platforms/chrp/setup.c:385:16: error: variable ‘idu_size’ set but not used [-Werror=unused-but-set-variable]
arch/powerpc/platforms/chrp/setup.c:526:13: error: no previous prototype for ‘chrp_init_IRQ’ [-Werror=missing-prototypes]
arch/powerpc/platforms/chrp/setup.c:559:1: error: no previous prototype for ‘chrp_init2’ [-Werror=missing-prototypes]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v2: Remove totally variable idu_size
arch/powerpc/platforms/chrp/setup.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
index 481ed133e04b..d6d8ffc0271e 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -94,7 +94,7 @@ static const char *chrp_names[] = {
"Total Impact Briq"
};
-void chrp_show_cpuinfo(struct seq_file *m)
+static void chrp_show_cpuinfo(struct seq_file *m)
{
int i, sdramen;
unsigned int t;
@@ -299,7 +299,7 @@ static __init void chrp_init(void)
of_node_put(node);
}
-void __init chrp_setup_arch(void)
+static void __init chrp_setup_arch(void)
{
struct device_node *root = of_find_node_by_path("/");
const char *machine = NULL;
@@ -382,7 +382,7 @@ static void __init chrp_find_openpic(void)
{
struct device_node *np, *root;
int len, i, j;
- int isu_size, idu_size;
+ int isu_size;
const unsigned int *iranges, *opprop = NULL;
int oplen = 0;
unsigned long opaddr;
@@ -427,11 +427,9 @@ static void __init chrp_find_openpic(void)
}
isu_size = 0;
- idu_size = 0;
if (len > 0 && iranges[1] != 0) {
printk(KERN_INFO "OpenPIC irqs %d..%d in IDU\n",
iranges[0], iranges[0] + iranges[1] - 1);
- idu_size = iranges[1];
}
if (len > 1)
isu_size = iranges[3];
@@ -523,7 +521,7 @@ static void __init chrp_find_8259(void)
}
}
-void __init chrp_init_IRQ(void)
+static void __init chrp_init_IRQ(void)
{
#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(CONFIG_XMON)
struct device_node *kbd;
@@ -555,7 +553,7 @@ void __init chrp_init_IRQ(void)
#endif
}
-void __init
+static void __init
chrp_init2(void)
{
#ifdef CONFIG_NVRAM
--
2.11.0
^ permalink raw reply related
* [PATCH v2 07/19] powerpc/powermac: Make some functions static
From: Mathieu Malaterre @ 2018-03-28 19:39 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-8-malat@debian.org>
These functions can all be static, make it so. Fix warnings treated as
errors with W=1:
arch/powerpc/platforms/powermac/pci.c:1022:6: error: no previous prototype for ‘pmac_pci_fixup_ohci’ [-Werror=missing-prototypes]
arch/powerpc/platforms/powermac/pci.c:1057:6: error: no previous prototype for ‘pmac_pci_fixup_cardbus’ [-Werror=missing-prototypes]
arch/powerpc/platforms/powermac/pci.c:1094:6: error: no previous prototype for ‘pmac_pci_fixup_pciata’ [-Werror=missing-prototypes]
Remove has_address declaration and assignment since not used. Also add gcc
attribute unused to fix a warning treated as error with W=1:
arch/powerpc/platforms/powermac/pci.c:784:19: error: variable ‘has_address’ set but not used [-Werror=unused-but-set-variable]
arch/powerpc/platforms/powermac/pci.c:907:22: error: variable ‘ht’ set but not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v2: remove has_address variable since not used
arch/powerpc/platforms/powermac/pci.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
index 0b8174a79993..67c497093e0a 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -781,12 +781,12 @@ static int __init pmac_add_bridge(struct device_node *dev)
struct resource rsrc;
char *disp_name;
const int *bus_range;
- int primary = 1, has_address = 0;
+ int primary = 1;
DBG("Adding PCI host bridge %pOF\n", dev);
/* Fetch host bridge registers address */
- has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+ of_address_to_resource(dev, 0, &rsrc);
/* Get bus range if any */
bus_range = of_get_property(dev, "bus-range", &len);
@@ -904,7 +904,7 @@ static int pmac_pci_root_bridge_prepare(struct pci_host_bridge *bridge)
void __init pmac_pci_init(void)
{
struct device_node *np, *root;
- struct device_node *ht = NULL;
+ struct device_node *ht __maybe_unused = NULL;
pci_set_flags(PCI_CAN_SKIP_ISA_ALIGN);
@@ -1019,7 +1019,7 @@ static bool pmac_pci_enable_device_hook(struct pci_dev *dev)
return true;
}
-void pmac_pci_fixup_ohci(struct pci_dev *dev)
+static void pmac_pci_fixup_ohci(struct pci_dev *dev)
{
struct device_node *node = pci_device_to_OF_node(dev);
@@ -1054,7 +1054,7 @@ void __init pmac_pcibios_after_init(void)
}
}
-void pmac_pci_fixup_cardbus(struct pci_dev* dev)
+static void pmac_pci_fixup_cardbus(struct pci_dev *dev)
{
if (!machine_is(powermac))
return;
@@ -1091,7 +1091,7 @@ void pmac_pci_fixup_cardbus(struct pci_dev* dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_TI, PCI_ANY_ID, pmac_pci_fixup_cardbus);
-void pmac_pci_fixup_pciata(struct pci_dev* dev)
+static void pmac_pci_fixup_pciata(struct pci_dev *dev)
{
u8 progif = 0;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 04/19] powerpc/kvm: Prefer fault_in_pages_readable function
From: Mathieu Malaterre @ 2018-03-28 19:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: LEROY Christophe, Mathieu Malaterre, Paul Mackerras,
Benjamin Herrenschmidt, kvm-ppc, linuxppc-dev, linux-kernel
In-Reply-To: <20180322202007.23088-5-malat@debian.org>
Directly use fault_in_pages_readable instead of manual __get_user code. Fix
warning treated as error with W=1:
arch/powerpc/kernel/kvm.c:675:6: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v2: use fault_in_pages_readable instead
arch/powerpc/kernel/kvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index 9ad37f827a97..124c51030b75 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -25,6 +25,7 @@
#include <linux/kvm_para.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/pagemap.h>
#include <asm/reg.h>
#include <asm/sections.h>
@@ -672,14 +673,13 @@ static void kvm_use_magic_page(void)
{
u32 *p;
u32 *start, *end;
- u32 tmp;
u32 features;
/* Tell the host to map the magic page to -4096 on all CPUs */
on_each_cpu(kvm_map_magic_page, &features, 1);
/* Quick self-test to see if the mapping works */
- if (__get_user(tmp, (u32*)KVM_MAGIC_PAGE)) {
+ if (!fault_in_pages_readable((const char *)KVM_MAGIC_PAGE, sizeof(u32))) {
kvm_patching_worked = false;
return;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v4 14/16] powerpc: Use generic free_initrd_mem.
From: Shea Levy @ 2018-03-28 20:36 UTC (permalink / raw)
To: linux-riscv, linux-kernel
Cc: Shea Levy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Michal Hocko, Vlastimil Babka, Andrew Morton,
Dan Williams, Christophe Leroy, Oliver O'Halloran,
Joe Perches, linuxppc-dev
In-Reply-To: <20180328203659.18692-1-shea@shealevy.com>
Signed-off-by: Shea Levy <shea@shealevy.com>
---
arch/powerpc/mm/mem.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index fe8c61149fb8..e85b2a3cd264 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -404,13 +404,6 @@ void free_initmem(void)
free_initmem_default(POISON_FREE_INITMEM);
}
-#ifdef CONFIG_BLK_DEV_INITRD
-void __init free_initrd_mem(unsigned long start, unsigned long end)
-{
- free_reserved_area((void *)start, (void *)end, -1, "initrd");
-}
-#endif
-
/*
* This is called when a page has been modified by the kernel.
* It just marks the page as not i-cache clean. We do the i-cache
--
2.16.2
^ permalink raw reply related
* Re: [PATCH] powerpc/64: Fix checksum folding in csum_add
From: Paul Mackerras @ 2018-03-28 20:40 UTC (permalink / raw)
To: LEROY Christophe
Cc: Shile Zhang, linuxppc-dev, Michael Ellerman,
Benjamin Herrenschmidt
In-Reply-To: <20180327172232.Horde.q3HjdRzVlIYmg2LP87jw8A1@messagerie.si.c-s.fr>
On Tue, Mar 27, 2018 at 05:22:32PM +0200, LEROY Christophe wrote:
> Shile Zhang <shile.zhang@nokia.com> 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 <shile.zhang@nokia.com>
> >---
> > arch/powerpc/include/asm/checksum.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/arch/powerpc/include/asm/checksum.h
> >b/arch/powerpc/include/asm/checksum.h
> >index 5b1a6e3..430d038 100644
> >--- a/arch/powerpc/include/asm/checksum.h
> >+++ b/arch/powerpc/include/asm/checksum.h
> >@@ -108,7 +108,7 @@ static inline __wsum csum_add(__wsum csum, __wsum addend)
> >
> > #ifdef __powerpc64__
> > res += (__force u64)addend;
> >- return (__force __wsum)((u32)res + (res >> 32));
> >+ return (__force __wsum) from64to32(res);
>
> Did you encounter a bug due to that ?
> As far as i understand, csum and addend are 32 bits so can't exceed 0xffffffff
> Then their sum won't exceed 0x1fffffffe. So the sum of upper and lower part
> won't carry
If the sum of the two halves was 0x1fffffffe, then that previously got
truncated to 32 bits and returned as 0xfffffffe, which is wrong - the
result should be 0xffffffff.
Paul.
^ permalink raw reply
* Re: [PATCH v4 14/16] powerpc: Use generic free_initrd_mem.
From: Joe Perches @ 2018-03-28 20:44 UTC (permalink / raw)
To: Shea Levy, linux-riscv, linux-kernel
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Michal Hocko, Vlastimil Babka, Andrew Morton, Dan Williams,
Christophe Leroy, Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20180328203659.18692-15-shea@shealevy.com>
On Wed, 2018-03-28 at 16:36 -0400, Shea Levy wrote:
> Signed-off-by: Shea Levy <shea@shealevy.com>
Most people seem to want some form of commit message
and not just your sign-off.
And btw:
It seems you used get_maintainer to determine who to
send these patches to.
I suggest you add --nogit and --nogit-fallback to the
get_maintainer command line you use to avoid sending
these patches to people like me that have done drive-by
cleanup work on these files.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox