Le 10/12/2019 à 05:47, Daniel Axtens a écrit :
KASAN support on powerpc64 is challenging:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run some code in real mode after boot, most notably a lot of
KVM code. We'd
add testcases for divde, divde., divdeu, divdeu. emulated
instructions to cover few scenarios,
* with same dividend and divisor to have undefine RT
for divdeu[.]
* with divide by zero to have undefine RT for both
divde[.] and divdeu[.]
* with negative
This patch adds emulation support for divde, divdeu instructions,
* Divide Doubleword Extended (divde[.])
* Divide Doubleword Extended Unsigned (divdeu[.])
Signed-off-by: Balamuruhan S
---
arch/powerpc/lib/sstep.c | 27 ++-
1 file changed, 26
Hi All,
This patchset adds support to emulate divde, divde., divdeu and divdeu.
instructions and testcases for it.
I would request for your review and suggestions for making it better.
Boot Log:
:: ::
:: ::
[2.732268] emulate_step_test: divde : RA = LONG_MIN, RB =
include instruction opcodes for divde, divde_dot, divideu and
divideu_dot as macros.
Signed-off-by: Balamuruhan S
---
arch/powerpc/include/asm/ppc-opcode.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h
Le 10/12/2019 à 05:47, Daniel Axtens a écrit :
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
Reviewed-by: Christophe Leroy
---
Documentation/dev-tools/kasan.rst | 3 ++-
Le 10/12/2019 à 05:47, Daniel Axtens a écrit :
This helps with powerpc support, and should have no effect on
anything else.
As explained in previous patch, this patch is based on MAX_PTRS_PER_Pxx
existing for every arch using KASAN, allthought all arches but powerpc
will define it as
Le 10/12/2019 à 05:47, Daniel Axtens a écrit :
powerpc has boot-time configurable PTRS_PER_PTE, PMD and PUD. The
values are selected based on the MMU under which the kernel is
booted. This is much like how 4 vs 5-level paging on x86_64 leads to
boot-time configurable PTRS_PER_P4D.
So far,
On 12/9/19 3:46 PM, John Hubbard wrote:
On 12/9/19 2:53 PM, John Hubbard wrote:
...
@@ -212,10 +211,9 @@ static void mm_iommu_unpin(struct
mm_iommu_table_group_mem_t *mem)
if (!page)
continue;
- if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
-
On 12/9/19 4:56 PM, Andrew Morton wrote:
On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote:
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just
Peter Zijlstra writes:
> On Fri, Dec 06, 2019 at 11:46:11PM +1100, Michael Ellerman wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi Linus,
>>
>> Please pull another powerpc update for 5.5.
>>
>> As you'll see from the diffstat this is mostly not powerpc code. In order to
On 10/12/2019 16:12, Ram Pai wrote:
> On Tue, Dec 10, 2019 at 02:07:36PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 07/12/2019 12:12, Ram Pai wrote:
>>> H_PUT_TCE_INDIRECT hcall uses a page filled with TCE entries, as one of
>>> its parameters. On secure VMs, hypervisor cannot access the
On Tue, Dec 10, 2019 at 02:07:36PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 07/12/2019 12:12, Ram Pai wrote:
> > H_PUT_TCE_INDIRECT hcall uses a page filled with TCE entries, as one of
> > its parameters. On secure VMs, hypervisor cannot access the contents of
> > this page since it gets
Christophe Leroy writes:
> Le 07/08/2019 à 01:38, Daniel Axtens a écrit :
>> KASAN support on powerpc64 is interesting:
>>
>> - We want to be able to support inline instrumentation so as to be
>> able to catch global and stack issues.
>>
>> - We run a lot of code at boot in real mode.
Christophe Leroy writes:
> Le 07/08/2019 à 01:38, Daniel Axtens a écrit :
>> powerpc supports several different MMUs. In particular, book3s
>> machines support both a hash-table based MMU and a radix MMU.
>> These MMUs support different numbers of entries per directory
>> level: the PTES_PER_*
KASAN support on powerpc64 is challenging:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run some code in real mode after boot, most notably a lot of
KVM code. We'd like to be able to instrument this.
[For those not
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
Documentation/dev-tools/kasan.rst | 3 ++-
Documentation/powerpc/kasan.txt | 12
2 files changed, 14 insertions(+), 1 deletion(-)
create mode
This helps with powerpc support, and should have no effect on
anything else.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 6 +++---
mm/kasan/init.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/kasan.h
powerpc has boot-time configurable PTRS_PER_PTE, PMD and PUD. The
values are selected based on the MMU under which the kernel is
booted. This is much like how 4 vs 5-level paging on x86_64 leads to
boot-time configurable PTRS_PER_P4D.
So far, this hasn't leaked out of arch/powerpc. But with
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
This provides full inline instrumentation on radix, but does require
that you be able to specify the amount of physically contiguous memory
on the system at compile time.
On 07/12/2019 12:12, Ram Pai wrote:
> Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
> secure guests")
> disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
> path for secure VMs, helped enable dma_direct path. This enabled
> support for
On 07/12/2019 12:12, Ram Pai wrote:
> H_PUT_TCE_INDIRECT hcall uses a page filled with TCE entries, as one of
> its parameters. On secure VMs, hypervisor cannot access the contents of
> this page since it gets encrypted. Hence share the page with the
> hypervisor, and unshare when done.
I
+ Shawn,
> -Original Message-
> From: Michael Walle
> Sent: Tuesday, December 10, 2019 8:06 AM
> To: Yinbo Zhu
> Cc: Ashish Kumar ; Alexandru Marginean
> ; Alison Wang ;
> Amit Jain (aj) ; catalin.horghi...@nxp.com; Claudiu
> Manoil ; devicet...@vger.kernel.org; Jiafei Pan
> ; Leo Li ;
On Mon, Dec 9, 2019 at 7:35 AM Sebastian Andrzej Siewior
wrote:
>
> On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
> > Is there a memory usage issue for the systems that led to this thread?
>
> No, no memory issue led to this thread. I was just testing my patch and
> I assumed that I did
On 12/9/19 1:40 PM, Greg KH wrote:
> On Mon, Dec 09, 2019 at 10:28:23AM +0530, Sourabh Jain wrote:
>> +#define CREATE_SYMLINK(target, symlink_name) do {\
>> +rc = compat_only_sysfs_link_entry_to_kobj(kernel_kobj, fadump_kobj, \
>> + target,
On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote:
> After DMA is complete, and the device and CPU caches are synchronized,
> it's still required to mark the CPU pages as dirty, if the data was
> coming from the device. However, this driver was just issuing a
> bare put_page() call, without
On Mon, 9 Dec 2019 11:55:13 +0100
Frederic Barrat wrote:
> If we couldn't fully init a context, we were leaking memory.
>
> Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
> Signed-off-by: Frederic Barrat
> ---
Reviewed-by: Greg Kurz
> Changlog:
> v3:
>
> dcfg use little endian that SoC register value will be correct
>
> Signed-off-by: Yinbo Zhu
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This patch is still missing. Any news?
Tested-by: Michael Walle
> diff --git
On 12/9/19 2:53 PM, John Hubbard wrote:
...
> @@ -212,10 +211,9 @@ static void mm_iommu_unpin(struct
> mm_iommu_table_group_mem_t *mem)
> if (!page)
> continue;
>
> - if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
> -
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via unpin_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
In order to provide a clearer, more symmetric API for pinning
and unpinning DMA pages. This way, pin_user_pages*() calls
match up with unpin_user_pages*() calls, and the API is a lot
closer to being self-explanatory.
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more
Convert infiniband to use the new pin_user_pages*() calls.
Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.
The new
1. Change v4l2 from get_user_pages() to pin_user_pages().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
A subsequent patch requires access to gup flags, so pass the flags
argument through to the __gup_device_* functions.
Also placate checkpatch.pl by shortening a nearby line.
TODO: Christoph Hellwig requested folding this into the patch the uses
the gup flags arguments.
Reviewed-by: Jan Kara
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Leon Romanovsky
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Jason Gunthorpe
1. Change vfio from get_user_pages_remote(), to
pin_user_pages_remote().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Note that this effectively changes the code's behavior in
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of
Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed
only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast().
This, combined with the fact that get_user_pages_fast() falls back to
"slow gup", which *does* accept FOLL_FORCE, leads to an odd situation:
if you need
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
For now, these are placeholder calls, until the various call sites
are converted to use the correct get_user_pages*() or
pin_user_pages*() API.
These variants will eventually all set
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
Update VFIO to take advantage of the recently loosened restriction on
FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to
fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it
wasn't setting FOLL_LONGTERM.
Also, remove an unnessary pair of calls that were
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "goldfish_pin_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jan Kara
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static
Hi,
This implements an API naming change (put_user_page*() -->
unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It
extends that tracking to a few select subsystems. More subsystems will
be added in follow up work.
Christoph Hellwig, a couple of points of interest:
a) I've
From: Dan Williams
After the removal of the device-public infrastructure there are only 2
->page_free() call backs in the kernel. One of those is a device-private
callback in the nouveau driver, the other is a generic wakeup needed in
the DAX case. In the hopes that all ->page_free() callbacks
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
mm/gup.c | 29
On Mon, 2019-12-09 at 12:27 -0800, Lakshmi Ramasubramanian wrote:
> Hi Mimi,
>
> On 10/30/2019 8:31 PM, Mimi Zohar wrote:
>
> > This patchset extends the previous version[1] by adding support for
> > checking against a blacklist of binary hashes.
> >
> > The IMA subsystem supports custom,
On 2019-12-09 2:00 p.m., Dan Williams wrote:
Can we fiddle that into "struct mhp_restrictions" instead?
>>>
>>> Yes, if that's what people want, it's pretty trivial to do. I chose not
>>> to do it that way because it doesn't get passed down to add_pages() and
>>> it's not really a
On 2019-12-09 1:41 p.m., Michal Hocko wrote:
> On Mon 09-12-19 13:24:19, Logan Gunthorpe wrote:
>>
>>
>> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
>>> On 09.12.19 20:13, Logan Gunthorpe wrote:
devm_memremap_pages() is currently used by the PCI P2PDMA code to create
struct
On Mon, Dec 9, 2019 at 12:47 PM Michal Hocko wrote:
>
> On Mon 09-12-19 13:24:19, Logan Gunthorpe wrote:
> >
> >
> > On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> > > On 09.12.19 20:13, Logan Gunthorpe wrote:
> > >> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
>
> Am 09.12.2019 um 21:43 schrieb Dan Williams :
>
> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe wrote:
>>
>>
>>
>>> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
>>> On 09.12.19 20:13, Logan Gunthorpe wrote:
devm_memremap_pages() is currently used by the PCI P2PDMA code to
On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe wrote:
>
>
>
> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> > On 09.12.19 20:13, Logan Gunthorpe wrote:
> >> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
> >> struct page mappings for IO memory. At present, these
On Mon, Dec 09, 2019 at 12:13:40PM -0700, Logan Gunthorpe wrote:
> This changes is pretty routine for most of the arches: x86_64, s390, arm64
> and powerpc simply need to thread the pgprot through to where the page tables
> are setup. x86_32 unfortunately sets up the page tables at boot so
> must
On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> On 09.12.19 20:13, Logan Gunthorpe wrote:
>> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
>> struct page mappings for IO memory. At present, these mappings are created
>> with PAGE_KERNEL which implies setting the
On Mon 09-12-19 13:24:19, Logan Gunthorpe wrote:
>
>
> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> > On 09.12.19 20:13, Logan Gunthorpe wrote:
> >> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
> >> struct page mappings for IO memory. At present, these
Hi Mimi,
On 10/30/2019 8:31 PM, Mimi Zohar wrote:
This patchset extends the previous version[1] by adding support for
checking against a blacklist of binary hashes.
The IMA subsystem supports custom, built-in, arch-specific policies to
define the files to be measured and appraised. These
On Thu, Nov 28, 2019 at 8:59 AM Rasmus Villemoes
wrote:
>
> There have been several attempts in the past few years to allow
> building the QUICC engine drivers for platforms other than PPC32. This
> is yet another attempt.
>
> v5 can be found here:
>
Clang warns:
../arch/powerpc/boot/4xx.c:231:3: warning: misleading indentation;
statement is not part of the previous 'else' [-Wmisleading-indentation]
val = SDRAM0_READ(DDR0_42);
^
../arch/powerpc/boot/4xx.c:227:2: note: previous statement is here
else
^
This is
In prepartion to support a pgprot_t argument for arch_add_memory().
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Signed-off-by: Logan Gunthorpe
---
arch/powerpc/include/asm/book3s/64/hash.h | 3 ++-
arch/powerpc/include/asm/book3s/64/radix.h | 3 ++-
In prepartion to support a pgprot_t argument for arch_add_memory().
It's required to move the prototype of init_memory_mapping() seeing
the original location came before the definition of pgprot_t.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
devm_memremap_pages() is currently used by the PCI P2PDMA code to create
struct page mappings for IO memory. At present, these mappings are created
with PAGE_KERNEL which implies setting the PAT bits to be WB. However, on
x86, an mtrr register will typically override this and force the cache
type
For use in the 32bit arch_add_memory() to set the pgprot type of the
memory to add.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Signed-off-by: Logan Gunthorpe
---
Hi,
Currently, the page tables created using memremap_pages() are always
created with the PAGE_KERNEL cacheing mode. However, the P2PDMA code
is creating pages for PCI BAR memory which should never be accessed
through the cache and instead use either WC or UC. This still works in
most cases, on
In prepartion to support a pgprot_t argument for arch_add_memory().
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Signed-off-by: Logan Gunthorpe
---
arch/s390/include/asm/pgtable.h | 3 ++-
arch/s390/mm/extmem.c | 3 ++-
arch/s390/mm/init.c | 2 +-
PCI BAR IO memory should never be mapped as WB, however prior to this
the PAT bits were set WB and it was typically overridden by MTRR
registers set by the firmware.
Set PCI P2PDMA memory to be WC (writecombining) as the only current
user (the NVMe CMB) was originally mapped WC before the P2PDMA
On 09.12.19 20:13, Logan Gunthorpe wrote:
> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
> struct page mappings for IO memory. At present, these mappings are created
> with PAGE_KERNEL which implies setting the PAT bits to be WB. However, on
> x86, an mtrr register will
The patch
spi: fsl: don't map irq during probe
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: fsl_sai: add IRQF_SHARED
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
On Mon, Dec 09, 2019 at 06:46:36PM +0100, Christophe Leroy wrote:
>
>
> Le 09/12/2019 à 16:09, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > Implement primitives necessary for the 4th level folding, add walks of p4d
> > level where appropriate and replace 5level-fixup.h with
Le 09/12/2019 à 16:09, Mike Rapoport a écrit :
From: Mike Rapoport
Implement primitives necessary for the 4th level folding, add walks of p4d
level where appropriate and replace 5level-fixup.h with pgtable-nop4d.h.
Signed-off-by: Mike Rapoport
Tested on 8xx and 83xx, no problem observed
Le 09/12/2019 à 14:26, Andrew Donnellan a écrit :
On 9/12/19 10:50 pm, Christophe Leroy wrote:
-extern unsigned long __clear_user(void __user *addr, unsigned long
size);
+extern unsigned long clear_user_asm(void __user *addr, unsigned long
size);
static inline unsigned long
With lastest kernel, the following warning is observed at startup:
[1.500609] [ cut here ]
[1.505225] remove_proc_entry: removing non-empty directory 'irq/22',
leaking at least 'fsl_spi'
[1.514234] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:682
No need to 'goto err;' for just doing a return.
return directly from where the error happens.
Signed-off-by: Christophe Leroy
---
drivers/spi/spi-fsl-spi.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-fsl-spi.c
From: Mike Rapoport
Implement primitives necessary for the 4th level folding, add walks of p4d
level where appropriate and replace 5level-fixup.h with pgtable-nop4d.h.
Signed-off-by: Mike Rapoport
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 1 -
On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
> Is there a memory usage issue for the systems that led to this thread?
No, no memory issue led to this thread. I was just testing my patch and
I assumed that I did something wrong in the counting/lock drop/lock
acquire/allocate path because
On 9/12/19 9:55 pm, Frederic Barrat wrote:
If we couldn't fully init a context, we were leaking memory.
Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
Signed-off-by: Frederic Barrat
Acked-by: Andrew Donnellan
--
Andrew Donnellan OzLabs, ADL
On 9/12/19 10:50 pm, Christophe Leroy wrote:
-extern unsigned long __clear_user(void __user *addr, unsigned long
size);
+extern unsigned long clear_user_asm(void __user *addr, unsigned long
size);
static inline unsigned long clear_user(void __user *addr, unsigned
long size)
{
@@ -409,12
The KUAP implementation adds calls in clear_user() to enable and disable
access to userspace memory. However, it doesn't add these to
__clear_user(), which is used in the ptrace regset code.
As there's only one direct user of __clear_user(), and the time taken to
set the AMR for KUAP purposes is
On 9/12/19 10:50 pm, Christophe Leroy wrote:
Le 09/12/2019 à 11:59, Andrew Donnellan a écrit :
The KUAP implementation adds calls in clear_user() to enable and disable
access to userspace memory. However, it doesn't add these to
__clear_user(), which is used in the ptrace regset code.
As
On 09/12/2019 11:08, Michael Ellerman wrote:
> Steven Price writes:
>> walk_page_range() is going to be allowed to walk page tables other than
>> those of user space. For this it needs to know when it has reached a
>> 'leaf' entry in the page tables. This information is provided by the
>>
Le 09/12/2019 à 11:59, Andrew Donnellan a écrit :
The KUAP implementation adds calls in clear_user() to enable and disable
access to userspace memory. However, it doesn't add these to
__clear_user(), which is used in the ptrace regset code.
As there's only one direct user of __clear_user(),
David Hildenbrand writes:
> On 14.11.19 14:19, David Hildenbrand wrote:
>> This is the MM part of
>> https://lkml.org/lkml/2019/10/31/487
>>
>> "We can get rid of the memory isolate notifier by switching to balloon
>> compaction in powerpc's CMM (Collaborative Memory Management). The memory
Steven Price writes:
> walk_page_range() is going to be allowed to walk page tables other than
> those of user space. For this it needs to know when it has reached a
> 'leaf' entry in the page tables. This information is provided by the
> p?d_leaf() functions/macros.
>
> For powerpc pmd_large()
The KUAP implementation adds calls in clear_user() to enable and disable
access to userspace memory. However, it doesn't add these to
__clear_user(), which is used in the ptrace regset code.
As there's only one direct user of __clear_user(), and the time taken to
set the AMR for KUAP purposes is
If we couldn't fully init a context, we were leaking memory.
Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
Signed-off-by: Frederic Barrat
---
Changlog:
v3:
code cleanup (Greg)
v2:
reset context pointer in case of allocation failure (Andrew)
Segher Boessenkool writes:
> On Sat, Dec 07, 2019 at 10:42:28AM +0100, Christophe Leroy wrote:
>> Le 06/12/2019 à 21:59, Segher Boessenkool a écrit :
>> >If the compiler can see the callee wants the same TOC as the caller has,
>> >it does not arrange to set (and restore) it, no. If it sees it
Kajol Jain writes:
> Many of the performance moniroting unit (PMU) SPRs are
> exposed in the sysfs. "perf" API is the primary interface to program
> PMU and collect counter data in the system. So expose these
> PMU SPRs in the absence of CONFIG_PERF_EVENTS.
>
> Patch adds a new CONFIG option
Hi,
On 12/5/19 2:02 PM, Srikar Dronamraju wrote:
> With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted
> vCPUs"), scheduler avoids preempted vCPUs to schedule tasks on wakeup.
> This leads to wrong choice of CPU, which in-turn leads to larger wakeup
> latencies.
Hi Christophe,
Thankyou for reviewing the patch.
On 12/5/19 11:28 AM, Christophe Leroy wrote:
Le 05/12/2019 à 06:25, Kajol Jain a écrit :
Many of the performance moniroting unit (PMU) SPRs are
exposed in the sysfs. "perf" API is the primary interface to program
PMU and collect
Hi!
On Mon, Dec 09, 2019 at 06:37:09AM +0100, Christophe Leroy wrote:
> What do you mean by NX ?
It is the Power9 "Nest Accelerator". The patch series should ideally
mention that right at the start, yeah.
> Up to now, NX has been standing for No-eXecute. That's a bit in segment
> registers on
1 - 100 of 102 matches
Mail list logo
