On Fri, 2020-01-31 at 07:58 +0100, Christophe Leroy wrote:
>
> Le 31/01/2020 à 07:53, Russell Currey a écrit :
> > On Fri, 2020-01-31 at 07:44 +0100, Christophe Leroy wrote:
> > > Le 31/01/2020 à 06:31, Russell Currey a écrit :
> > > > + pr_info("attempting bad read at %px with write
> > >
Le 31/01/2020 à 07:53, Russell Currey a écrit :
On Fri, 2020-01-31 at 07:44 +0100, Christophe Leroy wrote:
Le 31/01/2020 à 06:31, Russell Currey a écrit :
+ pr_info("attempting bad read at %px with write allowed\n",
ptr);
+ tmp = *ptr;
+ tmp += 0xc0dec0de;
+
On Fri, 2020-01-31 at 07:44 +0100, Christophe Leroy wrote:
>
> Le 31/01/2020 à 06:31, Russell Currey a écrit :
> > Kernel Userspace Access Prevention (KUAP) on powerpc supports
> > allowing only one access direction (Read or Write) when allowing
> > access
> > to or from user memory.
> >
> > A
Le 31/01/2020 à 06:31, Russell Currey a écrit :
Kernel Userspace Access Prevention (KUAP) on powerpc supports
allowing only one access direction (Read or Write) when allowing access
to or from user memory.
A bug was recently found that showed that these one-way unlocks never
worked, and
Kernel Userspace Access Prevention (KUAP) on powerpc supports
allowing only one access direction (Read or Write) when allowing access
to or from user memory.
A bug was recently found that showed that these one-way unlocks never
worked, and allowing Read *or* Write would actually unlock Read *and*
On Thu, Jan 30, 2020 at 12:06:01PM -0800, Dan Williams wrote:
> Kill this definition that was introduced in commit 41e94a851304 ("add
> devm_memremap_pages") add never used.
>
> Cc: Christoph Hellwig
> Signed-off-by: Dan Williams
Looks good,
Reviewed-by: Christoph Hellwig
On Thu, Jan 30, 2020 at 8:57 PM Alastair D'Silva wrote:
>
> On Fri, 2019-11-08 at 08:10 +0100, Frederic Barrat wrote:
> >
> > Le 25/10/2019 à 06:47, Alastair D'Silva a écrit :
> > > From: Alastair D'Silva
> > >
> > > Enable OpenCAPI Storage Class Memory driver on bare metal
> > >
> > >
On Fri, 2019-11-08 at 08:10 +0100, Frederic Barrat wrote:
>
> Le 25/10/2019 à 06:47, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > Enable OpenCAPI Storage Class Memory driver on bare metal
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> >
On Tue, 3 Dec 2019 14:36:38 +0100 Oscar Salvador wrote:
> On Mon, Dec 02, 2019 at 10:09:51AM +0100, David Hildenbrand wrote:
> > @Michal, @Oscar, can some of you at least have a patch #5 now so we can
> > proceed with that? (the other patches can stay in -next some time longer)
>
> Hi,
>
> I
On 1/29/20 10:31 PM, Oliver O'Halloran wrote:
> vio.c requires CONFIG_IBMVIO which in turn depends on PPC_PSERIES.
> In other words, this ifdef is pointless. At a guess it's a carry-over
> from pre-history.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Tyrel Datwyler
On 1/29/20 10:31 PM, Oliver O'Halloran wrote:
> The platform makefile (arch/powerpc/platforms/pseries/Makefile) is only
> included by the platform makefile (arch/powerpc/platform/Makefile) when
> CONFIG_PPC_PSERIES is selected, so checking for CONFIG_PPC_PSERIES in the
> pseries makefile is
On 1/29/20 10:36 PM, Sandipan Das wrote:
> v18:
> (1) Fixed issues with x86 multilib builds based on
> feedback from Dave.
> (2) Moved patch 2 to the end of the series.
These (finally) build and run successfully for me on an x86 system with
protection keys. Feel free to add
Hi!
On Thu, Jan 30, 2020 at 02:04:51PM -0300, Adhemerval Zanella wrote:
> On 30/01/2020 10:50, Segher Boessenkool wrote:
> > On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
> >>> This is why that *is* the only supported use. The documentation could
> >>> use a touch-up, I think.
The align attribute applies an alignment constraint for namespace
creation in a region. Whereas the 'align' attribute of a namespace
applied alignment padding via an info block, the 'align' attribute
applies alignment constraints to the free space allocation.
The default for 'align' is the
The NDD_ALIASING flag is used to indicate where pmem capacity might
alias with blk capacity and require labeling. It is also used to
indicate whether the DIMM supports labeling. Separate this latter
capability into its own flag so that the NDD_ALIASING flag is scoped to
true aliased
The pmem driver on PowerPC crashes with the following signature when
instantiating misaligned namespaces that map their capacity via
memremap_pages().
BUG: Unable to handle kernel data access at 0xc00100040600
Faulting instruction address: 0xc0090790
NIP [c0090790]
The "sub-section memory hotplug" facility allows memremap_pages() users
like libnvdimm to compensate for hardware platforms like x86 that have a
section size larger than their hardware memory mapping granularity. The
compensation that sub-section support affords is being tolerant of
physical
Kill this definition that was introduced in commit 41e94a851304 ("add
devm_memremap_pages") add never used.
Cc: Christoph Hellwig
Signed-off-by: Dan Williams
---
include/linux/io.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index
Aneesh reports that PowerPC requires 16MiB alignment for the address
range passed to devm_memremap_pages(), and Jeff reports that it is
possible to create a misaligned namespace which blocks future namespace
creation in that region. Both of these issues require namespace
alignment to be managed at
On 1/18/20 12:03 PM, Alexandre Ghiti wrote:
Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak
symbols that may be unresolved at link time which result in an absolute
relocation to 0. relocs_check.sh emits the following warning:
"WARNING: 2 bad relocations
c1a41478
On 1/29/2020 12:10 PM, Scott Cheloha wrote:
> On Tue, Jan 28, 2020 at 05:56:55PM -0600, Nathan Lynch wrote:
>> Scott Cheloha writes:
>>> LMB lookup is currently an O(n) linear search. This scales poorly when
>>> there are many LMBs.
>>>
>>> If we cache each LMB by both its base address and its
On 01/28/2020 06:57 AM, Anshuman Khandual wrote:
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table helpers or
CONFIG_ENABLE_WARN_DEPRECATED is gone since
commit 771c035372a0 ("deprecate the '__deprecated' attribute warnings
entirely and for good").
CONFIG_IOSCHED_DEADLINE and CONFIG_IOSCHED_CFQ are gone since
commit f382fb0bcef4 ("block: remove legacy IO schedulers").
The IOSCHED_DEADLINE was replaced
On 30/01/2020 10:50, Segher Boessenkool wrote:
> Hi again,
>
> On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
>>> This is why that *is* the only supported use. The documentation could
>>> use a touch-up, I think. Unless we still have problems here?
>>
>> I really don't know.
Hi,
I'm looking for the history of the tlbia macro. At the time being, the
tlbia macro performs 1024 tlbie, increasing the address by 0x1000
between each tlbie.
I looked into the fullhistory linux repository it was changed from 128
to 1024 at some point in time, but this was done in commit
powerpc is a bit special for VDSO as well as system calls in the
way that it requires setting CR SO bit which cannot be done in C.
Therefore, entry/exit needs to be performed in ASM.
Implementing __arch_get_vdso_data() would clobbers the link register,
requiring the caller to save it. As the ASM
On powerpc/32, GCC (8.1) generates pretty bad code for the
ns >>= vd->shift operation taking into account that the
shift is always <= 32 and the upper part of the result is
likely to be nul. GCC makes reversed assumptions considering
the shift to be likely >= 32 and the upper part to be like not
Some architectures have a fixed clocksource which is known at compile
time and cannot be replaced or disabled at runtime, e.g. timebase on
PowerPC. For such cases the clock mode check in the VDSO code is
pointless.
Therefore, give architectures the opportunity to redefine the way
clock_mode is
On powerpc, __arch_get_vdso_data() clobbers the link register,
requiring the caller to save it.
As the parent function already has to set a stack frame and saves
the link register before calling the C vdso function, retriving the
vdso data pointer there is lighter.
Give architectures the
On the same way as already done on PPC32, drop __get_datapage()
function and use get_datapage inline macro instead.
See commit ec0895f08f99 ("powerpc/vdso32: inline __get_datapage()")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso64/cacheflush.S | 9
The VDSO datapage and the text pages are always located immediately
next to each other, so it can be hardcoded without an indirection
through __kernel_datapage_offset
In order to ease things, move the data page in front like other
arches, that way there is no need to know the size of the library
This is a fifth version of a series to switch powerpc VDSO to generic
C implementation. All previous where RFCs. This one has reached a
mature status.
It is tested on PPC32 (mpc885 and mpc8321E).
It is build tested on kisskb
Le 30/01/2020 à 14:04, Anshuman Khandual a écrit :
On 01/28/2020 10:35 PM, Christophe Leroy wrote:
Le 28/01/2020 à 02:27, Anshuman Khandual a écrit :
diff --git a/arch/x86/include/asm/pgtable_64.h
b/arch/x86/include/asm/pgtable_64.h
index 0b6c4042942a..fb0e76d254b3 100644
---
Hi again,
On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
> > This is why that *is* the only supported use. The documentation could
> > use a touch-up, I think. Unless we still have problems here?
>
> I really don't know. GCC still has *some* support for the old behavior,
>
On 01/30/2020 12:57 PM, Mike Rapoport wrote:
> On Wed, Jan 29, 2020 at 11:20:44PM +0100, Gerald Schaefer wrote:
>> On Mon, 27 Jan 2020 22:33:08 -0500
>>
>> For example, who would have thought that pXd_bad() is supposed to
>> report large entries as bad? It's not really documented anywhere,
>
>
On 1/27/2020 1:49 PM, Laurentiu Tudor wrote:
>
>> -Original Message-
>> From: Andrei Botila
>> Sent: Monday, January 27, 2020 1:16 PM
>>
>> Add a new api that returns Management Complex firmware version
>> and make the required structure public. The api's first user will be
>> the caam
* Gautham R Shenoy [2020-01-30 16:27:47]:
> On Wed, Jan 29, 2020 at 07:21:21PM +0530, Srikar Dronamraju wrote:
>
> [..snip..]
>
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -1185,10 +1185,34 @@ static inline void add_cpu_to_smallcore_masks(int
> > cpu)
> >
On 01/30/2020 03:50 AM, Gerald Schaefer wrote:
> On Tue, 28 Jan 2020 06:57:53 +0530
> Anshuman Khandual wrote:
>
>> This adds tests which will validate architecture page table helpers and
>> other accessors in their compliance with expected generic MM semantics.
>> This will help various
On 01/28/2020 10:35 PM, Christophe Leroy wrote:
>
>
> Le 28/01/2020 à 02:27, Anshuman Khandual a écrit :
>> This adds tests which will validate architecture page table helpers and
>> other accessors in their compliance with expected generic MM semantics.
>> This will help various architectures
* Segher Boessenkool:
>> I *assumed* that I would still get
>> the value of r0 (the register) from the associated extended asm in this
>> expression, even if it may now be a different register. Your comment
>> made me think that this is undefined.
>
> Please show full(er) examples, I think we
On Thu, Jan 30, 2020 at 11:42:51AM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
> > No, that *is* supported: as input to or output from an asm, a local
> > register asm variable *is* guaranteed to live in the specified register.
> > This is the *only* supported use. Other uses may
Hello Srikar,
On Wed, Jan 29, 2020 at 07:21:21PM +0530, Srikar Dronamraju wrote:
[..snip..]
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1185,10 +1185,34 @@ static inline void add_cpu_to_smallcore_masks(int cpu)
> }
> }
>
> +int get_physical_package_id(int
* Segher Boessenkool:
> On Wed, Jan 29, 2020 at 06:02:34PM +0100, Florian Weimer wrote:
>> * Segher Boessenkool:
>>
>> > On Wed, Jan 29, 2020 at 05:19:19PM +0100, Florian Weimer wrote:
>> >> * Segher Boessenkool:
>> >> >> But GCC doesn't expose them as integers to C code, so you can't do much
>>
On 30/01/20 11:49 am, Sandipan Das wrote:
> Hi Dave,
>
> On 30/01/20 12:29 am, Dave Hansen wrote:
>> On 1/28/20 1:38 AM, Sandipan Das wrote:
>>> On 27/01/20 9:12 pm, Dave Hansen wrote:
How have you tested this patch (and the whole series for that matter)?
>>> I replaced the second
44 matches
Mail list logo
