(My apologies for however IBM's email client munges this)
> I heard it is going to be in Go 1.16.7, but I do not know much about Go.> Maybe the folks in Cc can chime in.
We have backports primed and ready for the next point release. They are waiting on the release manager to cherrypick them.
> On 28-Jul-2021, at 11:05 PM, Nathan Chancellor wrote:
>
> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
>> linux-next fails to boot on Power server (POWER8/POWER9). Following traces
>> are seen during boot
>>
>> [0.010799] software IO TLB: tearing down default memory
Transactional Memory was removed from the architecture in ISA v3.1. For
threads running in P8/P9 compatibility mode on P10 a synthetic TM
implementation is provided. In this implementation, tbegin. always sets
cr0 eq meaning the abort handler is always called. This is not an issue
as users of TM
ISA v3.1 removes TM but includes a synthetic implementation for
backwards compatibility. With this implementation, the tests
ptrace-tm-spd-gpr and ptrace-tm-gpr should never be able to make any
forward progress and eventually should be killed by the timeout.
Instead on a P10 running in P9 mode,
Excerpts from Nathan Chancellor's message of July 29, 2021 3:35 am:
> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
>> linux-next fails to boot on Power server (POWER8/POWER9). Following traces
>> are seen during boot
>>
>> [0.010799] software IO TLB: tearing down default
On Thu, 29 Jul 2021 10:00:51 +0800
Kefeng Wang wrote:
> On 2021/7/28 23:28, Steven Rostedt wrote:
> > On Wed, 28 Jul 2021 16:13:18 +0800
> > Kefeng Wang wrote:
> >
> >> The is_kernel[_text]() function check the address whether or not
> >> in kernel[_text] ranges, also they will check the
Excerpts from Fabiano Rosas's message of July 28, 2021 12:36 am:
> Nicholas Piggin writes:
>
>> Excerpts from Fabiano Rosas's message of July 27, 2021 6:17 am:
>>> If the nested hypervisor has no access to a facility because it has
>>> been disabled by the host, it should also not be able to see
On Fri, 16 Jul 2021 14:52:20 -0600, Tyrel Datwyler wrote:
> Prior to commit 1f4a4a19508d ("scsi: ibmvfc: Complete commands outside
> the host/queue lock") responses to commands were completed sequentially
> with the host lock held such that a command had a basic binary state of
> active or free.
On 2021/7/28 22:46, Steven Rostedt wrote:
On Wed, 28 Jul 2021 16:13:15 +0800
Kefeng Wang wrote:
The is_kernel_inittext/is_kernel_text/is_kernel function should not
include the end address(the labels _einittext, _etext and _end) when
check the address range, the issue exists since Linux
On 2021/7/28 23:32, Steven Rostedt wrote:
On Wed, 28 Jul 2021 16:13:19 +0800
Kefeng Wang wrote:
@@ -64,8 +64,7 @@ const struct exception_table_entry
*search_exception_tables(unsigned long addr)
int notrace core_kernel_text(unsigned long addr)
{
- if (addr >= (unsigned
On 2021/7/28 23:28, Steven Rostedt wrote:
On Wed, 28 Jul 2021 16:13:18 +0800
Kefeng Wang wrote:
The is_kernel[_text]() function check the address whether or not
in kernel[_text] ranges, also they will check the address whether
or not in gate area, so use better name.
Do you know what a
On 7/28/21 12:21 PM, Lukas Bulwahn wrote:
> The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
> supported.
>
> As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63
> ("ide: remove the legacy ide driver"), there is no need to mention
> HAVE_IDE in all those
On 7/28/21 11:21 AM, Lukas Bulwahn wrote:
> The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
> supported.
>
> As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63
> ("ide: remove the legacy ide driver"), there is no need to mention
> HAVE_IDE in all those
The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
supported.
As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63
("ide: remove the legacy ide driver"), there is no need to mention
HAVE_IDE in all those arch-specific Kconfig files.
The issue was identified
On POWER10 systems, the "ibm,thread-groups" property "2" indicates the cpus
in thread-group share both L2 and L3 caches. Hence, use cache_property = 2
itself to find both the L2 and L3 cache siblings.
Hence, create a new thread_group_l3_cache_map to keep list of L3 siblings,
but fill the mask
From: "Gautham R. Shenoy"
The helper function get_shared_cpu_map() was added in
'commit 500fe5f550ec ("powerpc/cacheinfo: Report the correct
shared_cpu_map on big-cores")'
and subsequently expanded upon in
'commit 0be47634db0b ("powerpc/cacheinfo: Print correct cache-sibling
map/list for L2
From: "Gautham R. Shenoy"
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share different sets of caches (Eg: On
Changes from v1 -> v2:
- Based on Gautham's comments, use a separate thread_group_l3_cache_map
and modify parsing code to build cache_map for L3. This makes the
cache_map building code isolated from the parsing code.
v1 can be found at:
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> linux-next fails to boot on Power server (POWER8/POWER9). Following traces
> are seen during boot
>
> [0.010799] software IO TLB: tearing down default memory pool
> [0.010805] [ cut here ]
> [
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> The locking is the same between the native and compat version of
> sys_kexec_load(), so it can be done in the common implementation
> to reduce duplication.
Acked-by: "Eric W. Biederman"
>
> Co-developed-by: Eric Biederman
> Co-developed-by:
On Wed, Jul 28, 2021 at 02:17:27PM +0100, Christoph Hellwig wrote:
> So common checks obviously make sense, but I really hate the stupid
> multiplexer. Having one well-documented helper per feature is much
> easier to follow.
We had that in x86 - it was called cpu_has_ where xxx is the
feature
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> kimage_alloc_init() expects a __user pointer, so compat_sys_kexec_load()
> uses compat_alloc_user_space() to convert the layout and put it back
> onto the user space caller stack.
>
> Moving the user space access into the syscall handler directly
On Wed, 28 Jul 2021 16:13:19 +0800
Kefeng Wang wrote:
> @@ -64,8 +64,7 @@ const struct exception_table_entry
> *search_exception_tables(unsigned long addr)
>
> int notrace core_kernel_text(unsigned long addr)
> {
> - if (addr >= (unsigned long)_stext &&
> - addr < (unsigned
On Wed, 28 Jul 2021 16:13:18 +0800
Kefeng Wang wrote:
> The is_kernel[_text]() function check the address whether or not
> in kernel[_text] ranges, also they will check the address whether
> or not in gate area, so use better name.
Do you know what a gate area is?
Because I believe gate area
On Wed, 28 Jul 2021 16:13:15 +0800
Kefeng Wang wrote:
> The is_kernel_inittext/is_kernel_text/is_kernel function should not
> include the end address(the labels _einittext, _etext and _end) when
> check the address range, the issue exists since Linux v2.6.12.
>
> Cc: Arnd Bergmann
> Cc: Sergey
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
> Introduce an x86 version of the prot_guest_has() function. This will be
> used in the more generic x86 code to replace vendor specific calls like
> sev_active(), etc.
>
> While the name suggests this is intended mainly for
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky via iommu wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to
Dear Michael,
Am 28.07.21 um 14:43 schrieb Michael Ellerman:
Paul Menzel writes:
Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a segmentation
fault [1], and it might be
Paul Menzel writes:
> Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
>> On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
>
>>> On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a segmentation
>>> fault [1], and it might be related to *[release-branch.go1.16] runtime:
>>> fix crash
v1: https://lkml.org/lkml/2021/7/26/1509
Changelog v1-->v2:
Based on comments from Gautham,
1. Included a #define for MAX_NR_CHIPS instead of hardcoding the
allocation.
Pratik R. Sampat (1):
cpufreq:powernv: Fix init_chip_info initialization in numa=off
drivers/cpufreq/powernv-cpufreq.c | 16
In the numa=off kernel command-line configuration init_chip_info() loops
around the number of chips and attempts to copy the cpumask of that node
which is NULL for all iterations after the first chip.
Hence, store the cpu mask for each chip instead of derving cpumask from
node while populating
Am 28.07.21 um 00:26 schrieb Tom Lendacky:
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to the
在 2021/7/28 下午5:01, Arnd Bergmann 写道:
On Wed, Jul 28, 2021 at 10:28 AM Xianting Tian
wrote:
在 2021/7/28 下午3:25, Arnd Bergmann 写道:
I checked several hvc backends, like drivers/tty/hvc/hvc_riscv_sbi.c,
drivers/tty/hvc/hvc_iucv.c, drivers/tty/hvc/hvc_rtas.c, they don't use dma.
I not finished
On Wed, Jul 28, 2021 at 10:28 AM Xianting Tian
wrote:
> 在 2021/7/28 下午3:25, Arnd Bergmann 写道:
>
> I checked several hvc backends, like drivers/tty/hvc/hvc_riscv_sbi.c,
> drivers/tty/hvc/hvc_iucv.c, drivers/tty/hvc/hvc_rtas.c, they don't use dma.
>
> I not finished all hvc backends check yet. But
Dear Benjamin,
Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a segmentation
fault [1], and it might be related to *[release-branch.go1.16] runtime:
fix crash during VDSO calls
The arch_set_user_pkey_access function never uses its first parameter
(struct task_struct *tsk). It is only able to set the pkey permissions for
the current task as implemented, and existing kernel code only passes
"current" to arch_set_user_pkey_access. So remove the ambiguous parameter
to make
The new is_kernel() check the kernel address ranges, and the
new is_kernel_text() check the kernel text section ranges.
Then use them to make some code clear.
Cc: Arnd Bergmann
Cc: Andrey Ryabinin
Signed-off-by: Kefeng Wang
---
include/asm-generic/sections.h | 27 +++
Move core_kernel_data() into sections.h and rename it to
is_kernel_core_data(), also make it return bool value, then
update all the callers.
Cc: Arnd Bergmann
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: "David S. Miller"
Signed-off-by: Kefeng Wang
---
include/asm-generic/sections.h | 14
Use is_kernel_text() and is_kernel_inittext() helper to simplify code,
also drop etext, _stext, _sinittext, _einittext declaration which
already declared in section.h.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Kefeng
The is_kernel_inittext() and init_kernel_text() are with same
functionality, let's just keep is_kernel_inittext() and move
it into sections.h, then update all the callers.
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Arnd Bergmann
Cc: x...@kernel.org
Signed-off-by: Kefeng Wang
---
The is_kernel[_text]() function check the address whether or not
in kernel[_text] ranges, also they will check the address whether
or not in gate area, so use better name.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Sami Tolvanen
Cc: Nathan Chancellor
Cc: Arnd Bergmann
Cc:
The is_kernel_inittext/is_kernel_text/is_kernel function should not
include the end address(the labels _einittext, _etext and _end) when
check the address range, the issue exists since Linux v2.6.12.
Cc: Arnd Bergmann
Cc: Sergey Senozhatsky
Cc: Petr Mladek
Acked-by: Sergey Senozhatsky
After commit 4ba66a976072 ("arch: remove blackfin port"),
no need arch-specific text/data check.
Cc: Arnd Bergmann
Signed-off-by: Kefeng Wang
---
include/asm-generic/sections.h | 16
include/linux/kallsyms.h | 3 +--
kernel/locking/lockdep.c | 3 ---
3 files
There are three head files(kallsyms.h, kernel.h and sections.h) which
include the kernel sections range check, let's make some cleanup and
unify them.
1. cleanup arch specific text/data check and fix address boundary check
in kallsyms.h
2. make all the basic/core kernel range check function
linux-next fails to boot on Power server (POWER8/POWER9). Following traces
are seen during boot
[0.010799] software IO TLB: tearing down default memory pool
[0.010805] [ cut here ]
[0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
[0.010812]
Crash recovery (fadump) is setup in the userspace by some service.
This service rebuilds initrd with dump capture capability, if it is
not already dump capture capable before proceeding to register for
firmware assisted dump (echo 1 > /sys/kernel/fadump/registered). But
arming the kernel with
46 matches
Mail list logo
