On Tue, Mar 29, 2022 at 05:32:18PM +, Christophe Leroy wrote:
>
>
> Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
> > Josh Poimboeuf writes:
> >> On Sun, Mar 27, 2022 at 09:09:20AM +, Christophe Leroy wrote:
> >>> Second point is the endianess and 32/64 selection, especially when
>
Tyrel,
> The adapter request_limit is hardcoded to be INITIAL_SRP_LIMIT which
> is currently an arbitrary value of 800. Increase this value to 1024
> which better matches the characteristics of the typical IBMi Initiator
> that supports 32 LUNs and a queue depth of 32.
Applied to
On Fri, 25 Mar 2022 09:03:08 +0100
Christophe Leroy wrote:
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
Small nit. Please order the includes in "upside-down x-mas tree" fashion:
#include
#include
On Fri, 25 Mar 2022 07:32:21 +0100
Christophe Leroy wrote:
> Most architectures have ftrace related stuff in arch/*/kernel/ftrace.c
> but powerpc has it spread in multiple files located in
> arch/powerpc/kernel/trace/
> In several architectures, there are also additional files containing
>
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-for-5.18
...to receive the libnvdimm update for this cycle which includes the
deprecation of block-aperture mode and a new perf events interface for
the papr_scm nvdimm driver. The perf
Wait for completion of write transfers before returning from the driver.
At first sight it may seem advantageous to leave write transfers queued
for the controller to carry out on its own time, but there's a couple of
issues with it:
* Driver doesn't check for FIFO space.
* The queued writes
Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
> Josh Poimboeuf writes:
>> On Sun, Mar 27, 2022 at 09:09:20AM +, Christophe Leroy wrote:
>>> Second point is the endianess and 32/64 selection, especially when
>>> crossbuilding. There is already some stuff regarding endianess based on
>>>
Right now, the last 5 bits (0x1f) of the swap entry are used for the
type and the bit before that (0x20) is used for _PAGE_SWP_SOFT_DIRTY. We
cannot use 0x40, as that collides with _RPAGE_RSV1 -- contained in
_PAGE_HPTEFLAGS. The next candidate would be _RPAGE_SW3 (0x200) -- which is
used for
The swap type is simply stored in bits 0x1f of the swap pte. Let's
simplify by just getting rid of _PAGE_BIT_SWAP_TYPE. It's not like that
we can simply change it: _PAGE_SWP_SOFT_DIRTY would suddenly fall into
_RPAGE_RSV1, which isn't possible and would make the
BUILD_BUG_ON(_PAGE_HPTEFLAGS &
Let's use bit 52, which is unused.
Signed-off-by: David Hildenbrand
---
arch/s390/include/asm/pgtable.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 3982575bb586..a397b072a580
Bit 52 and bit 55 don't have to be zero: they only trigger a
translation-specifiation exception if the PTE is marked as valid, which
is not the case for swap ptes.
Document which bits are used for what, and which ones are unused.
Signed-off-by: David Hildenbrand
---
Let's use one of the type bits: core-mm only supports 5, so there is no
need to consume 6.
Note that we might be able to reuse bit 1, but reusing bit 1 turned out
problematic in the past for PROT_NONE handling; so let's play safe and
use another bit.
Reviewed-by: Catalin Marinas
Signed-off-by:
Let's use bit 3 to remember PG_anon_exclusive in swap ptes.
Signed-off-by: David Hildenbrand
---
arch/x86/include/asm/pgtable.h | 16
arch/x86/include/asm/pgtable_64.h| 4 +++-
arch/x86/include/asm/pgtable_types.h | 5 +
3 files changed, 24 insertions(+), 1
Currently, we clear PG_anon_exclusive in try_to_unmap() and forget about
it. We do this, to keep fork() logic on swap entries easy and efficient:
for example, if we wouldn't clear it when unmapping, we'd have to lookup
the page in the swapcache for each and every swap entry during fork() and
clear
Let's test that __HAVE_ARCH_PTE_SWP_EXCLUSIVE works as expected.
Signed-off-by: David Hildenbrand
---
mm/debug_vm_pgtable.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index db2abd9e415b..55f1a8dc716f 100644
---
More information on the general COW issues can be found at [2]. This series
is based on latest linus/master and [1]:
[PATCH v3 00/16] mm: COW fixes part 2: reliable GUP pins of
anonymous pages
v2 is located at:
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the pseries vas sysfs code to use default_groups field
which has been the preferred way since aa30f47cf666 ("kobject: Add
support for default attribute
On Sat, Mar 26, 2022 at 6:00 PM Benjamin Stürz wrote:
>
> This replaces comments with C99's designated
> initializers because the kernel supports them now.
>
> Signed-off-by: Benjamin Stürz
> ---
> drivers/gpio/gpio-winbond.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Josh Poimboeuf writes:
> On Sun, Mar 27, 2022 at 09:09:20AM +, Christophe Leroy wrote:
>> Second point is the endianess and 32/64 selection, especially when
>> crossbuilding. There is already some stuff regarding endianess based on
>> bswap_if_needed() but that's based on constant selection
Laurent Dufour writes:
> On 29/03/2022, 10:31:33, Nicholas Piggin wrote:
>> Excerpts from Laurent Dufour's message of March 17, 2022 9:06 pm:
>>> RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits
>>> mode (MSR[SF] unset).
>>>
>>> The change in MSR is done in enter_rtas() in a
On Mon, 28 Mar 2022, Christophe Leroy wrote:
> All three versions of klp_arch_set_pc() do exactly the same: they
> call ftrace_instruction_pointer_set().
>
> Call ftrace_instruction_pointer_set() directly and remove
> klp_arch_set_pc().
>
> As klp_arch_set_pc() was the only thing remaining in
On Tue, Mar 29, 2022 at 02:15:19AM -0700, Qing Wang wrote:
> From: Wang Qing
>
> sched_domain_flags_f() are statically set now, but actually, we can get a lot
> of necessary information based on the cpu_map. e.g. we can know whether its
> cache is shared.
>
> Allows custom extension without
From: Wang Qing
default_topology does not fit arm64, especially CPU and cache topology.
Add arm64_topology, so we can do more based on CONFIG_GENERIC_ARCH_TOPOLOGY.
arm64_xxx_flags() prefer to get the cache attribute from DT.
Signed-off-by: Wang Qing
---
arch/arm64/kernel/smp.c | 56
From: Wang Qing
When ACPI is not enabled, we can get cache topolopy from DT like:
* cpu0: cpu@000 {
* next-level-cache = <_1>;
* L2_1: l2-cache {
* compatible = "cache";
*
From: Wang Qing
sched_domain_flags_f() are statically set now, but actually, we can get a lot
of necessary information based on the cpu_map. e.g. we can know whether its
cache is shared.
Allows custom extension without affecting current.
Signed-off-by: Wang Qing
---
arch/powerpc/kernel/smp.c
From: Wang Qing
We don't know anything about the cache topology info without ACPI,
but in fact we can get it from DT like:
* cpu0: cpu@000 {
* next-level-cache = <_1>;
* L2_1: l2-cache {
* compatible =
When the mmu_feature_keys[] was introduced in the commit c12e6f24d413
("powerpc: Add option to use jump label for mmu_has_feature()"),
it is unlikely that it would be used either directly or indirectly in
the out of tree modules. So we export it as GPL only. But with the
evolution of the codes,
On 29/03/2022, 10:31:33, Nicholas Piggin wrote:
> Excerpts from Laurent Dufour's message of March 17, 2022 9:06 pm:
>> RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits
>> mode (MSR[SF] unset).
>>
>> The change in MSR is done in enter_rtas() in a relatively complex way,
>> since the
On some Intel AlderLake platforms, Thunderbolt entering D3cold can cause
some errors reported by AER:
[ 30.100211] pcieport :00:1d.0: AER: Uncorrected (Non-Fatal) error
received: :00:1d.0
[ 30.100251] pcieport :00:1d.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal),
On some Intel AlderLake platforms, Thunderbolt entering D3cold can cause
some errors reported by AER:
[ 30.100211] pcieport :00:1d.0: AER: Uncorrected (Non-Fatal) error
received: :00:1d.0
[ 30.100251] pcieport :00:1d.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal),
Excerpts from Laurent Dufour's message of March 17, 2022 9:06 pm:
> RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits
> mode (MSR[SF] unset).
>
> The change in MSR is done in enter_rtas() in a relatively complex way,
> since the MSR value could be hardcoded.
>
> Furthermore, a
Excerpts from Christophe Leroy's message of March 27, 2022 5:32 pm:
> Using conditional branches between two files is hasardous,
> they may get linked to far from each other.
>
> arch/powerpc/kvm/book3s_64_entry.o:(.text+0x3ec): relocation truncated
> to fit: R_PPC64_REL14 (stub)
Excerpts from Fabiano Rosas's message of March 29, 2022 7:58 am:
> We removed most of the vcore logic from the P9 path but there's still
> a tracepoint that tried to dereference vc->runner.
Thanks for the fix.
Reviewed-by: Nicholas Piggin
>
> Fixes: ecb6a7207f92 ("KVM: PPC: Book3S HV P9:
33 matches
Mail list logo
