Xmon should be either fully or partially disabled depending on the
kernel lockdown state.
Put xmon into read-only mode for lockdown=integrity and completely
disable xmon when lockdown=confidentiality. Since this can occur
dynamically, there may be pre-existing, active breakpoints in xmon when
tran
Xmon should be either fully or partially disabled depending on the
kernel lockdown state.
Put xmon into read-only mode for lockdown=integrity and prevent user
entry into xmon when lockdown=confidentiality. Xmon checks the lockdown
state on every attempted entry:
(1) during early xmon'ing
(2) w
Read-only mode should not prevent listing and clearing any active
breakpoints.
Tested-by: Daniel Axtens
Reviewed-by: Daniel Axtens
Signed-off-by: Christopher M. Riedl
---
arch/powerpc/xmon/xmon.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc
/Juliet-Kim/net-ibmvnic-free-reset-work-of-removed-device-from-queue/20190906-195317
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
Helge Deller writes:
> On 06.09.19 23:47, Thiago Jung Bauermann wrote:
>> Helge Deller writes:
>>> This kexec patch series is the groundwork for kexec on the parisc
>>> architecture.
>>> Since we want kexec on parisc, I've applied it to my for-next-kexec tree
>>> [1],
>>> and can push it to
The commit 108c14858b9e ("locking/lockdep: Add support for dynamic
keys") introduced a boot warning on powerpc below, because since the
commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page allocat
On 06.09.19 23:47, Thiago Jung Bauermann wrote:
> Helge Deller writes:
>> This kexec patch series is the groundwork for kexec on the parisc
>> architecture.
>> Since we want kexec on parisc, I've applied it to my for-next-kexec tree [1],
>> and can push it to Linus in the next merge window throug
Helge Deller writes:
> Hi all,
>
> This kexec patch series is the groundwork for kexec on the parisc
> architecture.
> Since we want kexec on parisc, I've applied it to my for-next-kexec tree [1],
> and can push it to Linus in the next merge window through the parisc tree [2].
I just had a lo
Srikar Dronamraju writes:
>> Regardless, I have an annoying question :-) Isn't it possible that,
>> while Linux is calling vphn_get_nid() for each logical cpu in sequence,
>> the platform could change a virtual processor's node assignment,
>> potentially causing sibling threads to get different no
The commit 108c14858b9e ("locking/lockdep: Add support for dynamic
keys") introduced a boot warning on powerpc below, because since the
commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page allocat
On Fri, 6 Sep 2019 11:58:59 +0530
Anshuman Khandual wrote:
> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
> > On Thu, 5 Sep 2019 14:48:14 +0530
> > Anshuman Khandual wrote:
> >
> >>> [...]
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> +
On 9/5/2019 3:01 PM, Youri Querry wrote:
> The QBMan frame descriptor enqueuing is changed from array
> mode (a single frame enqueue at a time) to bulk ring mode.
>
> This new mode allows the enqueuing of multiple frames in one operation.
> The original interface is kept but use the bulk enqueue o
On Fri, Sep 06, 2019 at 05:06:39PM +0530, Bharata B Rao wrote:
> > Also is bit 56+ a set of values, so is there 1 << 56 and 3 << 56 as well?
> > Seems
> > like even that other patch doesn't fully define these "pfn" values.
>
> I realized that the bit numbers have changed, it is no longer bits 60
Hi Oliver,
On 9/4/19 8:37 AM, Oliver O'Halloran wrote:
> On Fri, 2019-08-16 at 19:50 +0300, Sergey Miroshnichenko wrote:
>> Add pcibios_rescan_prepare()/_done() hooks for the powerpc platform. Now if
>> the device's driver supports movable BARs, pcibios_rescan_prepare() will be
>> called after the
The pull request you sent on Fri, 06 Sep 2019 14:47:37 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.3-5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/13da6ac106be36d7c2d7f201fd8850a9ac235e6b
Thank you!
--
Deet-doot-do
Hi all,
This kexec patch series is the groundwork for kexec on the parisc architecture.
Since we want kexec on parisc, I've applied it to my for-next-kexec tree [1],
and can push it to Linus in the next merge window through the parisc tree [2].
If someone has any objections, or if you prefer to t
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file
> system on my P9 box running mainline kernel 5.3.0-rc5
Is the issue reproducible? And if yes, how reliably? Thanks.
With commit ("powerpc/numa: Early request for home node associativity"),
commit 2ea626306810 ("powerpc/topology: Get topology for shared
processors at boot") which was requesting home node associativity
becomes redundant.
Hence remove the late request for home node associativity.
Signed-off-by: S
All the sibling threads of a core have to be part of the same node.
To ensure that all the sibling threads map to the same node, always
lookup/update the cpu-to-node map of the first thread in the core.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Currently the kernel detects if its running on a shared lpar platform
and requests home node associativity before the scheduler sched_domains
are setup. However between the time NUMA setup is initialized and the
request for home node associativity, workqueue initializes its per node
cpumask. The pe
Currently code handles H_FUNCTION, H_SUCCESS, H_HARDWARE return codes.
However hcall_vphn can return other return codes. Now it also handles
H_PARAMETER return code. Also the rest return codes are handled under the
default case.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas
There is no value in unpacking associativity, if
H_HOME_NODE_ASSOCIATIVITY hcall has returned an error.
Signed-off-by: Srikar Dronamraju
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Satheesh Rajendran
Reported-by: Abdul Haleem
---
Changelog
Abdul reported a warning on a shared lpar.
"WARNING: workqueue cpumask: online intersect > possible intersect".
This is because per node workqueue possible mask is set very early in the
boot process even before the system was querying the home node
associativity. However per node workqueue online
> > Regardless, I have an annoying question :-) Isn't it possible that,
> > while Linux is calling vphn_get_nid() for each logical cpu in sequence,
> > the platform could change a virtual processor's node assignment,
> > potentially causing sibling threads to get different node assignments
> > and
On Mon, Sep 02, 2019 at 09:53:56AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 30, 2019 at 09:12:59AM +0530, Bharata B Rao wrote:
> > On Thu, Aug 29, 2019 at 10:38:10AM +0200, Christoph Hellwig wrote:
> > > On Thu, Aug 22, 2019 at 03:56:14PM +0530, Bharata B Rao wrote:
> > > > +/*
> > > > + * Bit
Hi,
The subjet is misleading. This isn't powerpc but only powerpc/64, and
this is not memcpy() but memcpy_mcsafe()
Christophe
Le 03/09/2019 à 23:43, Santosh Sivaraj a écrit :
For sizes lesser than 128 bytes, the code branches out early without saving
the stack frame, which when restored late
On 09/05/2019 02:29 PM, Kirill A. Shutemov wrote:
> On Thu, Sep 05, 2019 at 01:48:27PM +0530, Anshuman Khandual wrote:
+#define VADDR_TEST(PGDIR_SIZE + PUD_SIZE + PMD_SIZE + PAGE_SIZE)
>>>
>>> What is special about this address? How do you know if it is not occupied
>>> yet?
>>
>> W
27 matches
Mail list logo
