Currently we have 2 sets of interrupt controller hypercalls handlers
for real and virtual modes, this is from POWER8 times when switching
MMU on was considered an expensive operation.
POWER9 however does not have dependent threads and MMU is enabled for
handling hcalls so the XIVE native or
Nothing in termbits seems to require anything from linux/posix_types.h.
Signed-off-by: Ilpo Järvinen
---
arch/alpha/include/uapi/asm/termbits.h | 2 --
arch/mips/include/uapi/asm/termbits.h | 2 --
arch/parisc/include/uapi/asm/termbits.h | 2 --
arch/sparc/include/uapi/asm/termbits.h | 2 --
Right now 'char *' elements allocated individual 'stat_id' in
'papr_scm_priv.nvdimm_events_map' during papr_scm_pmu_check_events() leak in
papr_scm_remove() and papr_scm_pmu_register(), papr_scm_pmu_check_events() error
paths.
Also individual 'stat_id' arent NULL terminated 'char *' instead they
On Sun, May 08, 2022 at 05:36:41PM +0800, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When
On 5/9/22 15:18, Alexey Kardashevskiy wrote:
On 5/4/22 07:21, Nick Desaulniers wrote:
On Thu, Apr 28, 2022 at 11:46 PM Alexey Kardashevskiy
wrote:
This enables LTO_CLANG builds on POWER with the upstream version of
LLVM.
LTO optimizes the output vmlinux binary and this may affect the
Some defines are the same across all archs. Move the most obvious
intersection to termbits-common.h.
Signed-off-by: Ilpo Järvinen
---
arch/alpha/include/uapi/asm/termbits.h | 52 +
arch/mips/include/uapi/asm/termbits.h | 53 +-
Again, I prefer Greg to take these through his tty tree.
Changes done by this serie:
1) Create termbits-common.h for the most obvious termbits.h intersection.
2) Reformat some lines that remain in termbits.h files.
3) Don't include posix_types.h unnecessarily.
Please do check I got the uapi
On Sat, May 07, 2022 at 01:06:18AM -0700, Kees Cook wrote:
> On Sat, May 07, 2022 at 07:23:58AM +0200, Miguel Ojeda wrote:
> > ## Patch series status
> >
> > The Rust support is still to be considered experimental. However,
> > support is good enough that kernel developers can start working on
On Thu, May 05 2022 at 17:00, Ricardo Neri wrote:
> + if (is_hpet_hld_interrupt(hdata)) {
> + /*
> + * Kick the timer first. If the HPET channel is periodic, it
> + * helps to reduce the delta between the expected TSC value and
> + * its
On Mon, 9 May 2022, Helge Deller wrote:
> Hello Ilpo,
>
> On 5/9/22 11:34, Ilpo Järvinen wrote:
> > Some defines are the same across all archs. Move the most obvious
> > intersection to termbits-common.h.
>
> I like your cleanup patches, but in this specific one, does it makes sense
> to split
On 29/04/2022 13:04, Guilherme G. Piccoli wrote:
> On 27/04/2022 21:28, Randy Dunlap wrote:
>>
>>
>> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>>> + crash_kexec_post_notifiers
>>> + This was DEPRECATED - users should always prefer the
>>
>> This is
Josh Poimboeuf writes:
> With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative
> pointers are calculated weirdly: based on the beginning of the bug_entry
> struct address, rather than their respective pointer addresses.
>
> Make the relative pointers less surprising to both humans and
On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> The alpha panic notifier has some code issues, not following
> the conventions of other notifiers. Also, it might halt the
> machine but still it is set to run as early as possible, which
> doesn't seem to be a good idea.
>
> This patch cleans
On Thu, May 05 2022 at 17:00, Ricardo Neri wrote:
> Add a NMI_WATCHDOG as a new category of NMI handler. This new category
> is to be used with the HPET-based hardlockup detector. This detector
> does not have a direct way of checking if the HPET timer is the source of
> the NMI. Instead, it
Hello Ilpo,
On 5/9/22 11:34, Ilpo Järvinen wrote:
> Some defines are the same across all archs. Move the most obvious
> intersection to termbits-common.h.
I like your cleanup patches, but in this specific one, does it makes sense
to split up together-belonging constants, e.g.
> diff --git
On Fri, May 06, 2022 at 12:07:13PM -0700, Mike Kravetz wrote:
> On 5/3/22 03:03, Gerald Schaefer wrote:
> > On Tue, 3 May 2022 10:19:46 +0800
> > Baolin Wang wrote:
> >> On 5/2/2022 10:02 PM, Gerald Schaefer wrote:
[...]
> >> Please see previous code, we'll use the original pte value to check
On Mon, May 09, 2022 at 09:23:39PM +1000, Michael Ellerman wrote:
> Herbert Xu writes:
> > Hi:
> >
> > There are some code paths in the kernel where you can reliably
> > trigger a request_module of a non-existant module. For example,
> > if you attempt to load a non-existent crypto algorithm, or
On Fri, May 6, 2022 at 5:45 AM Clément Léger wrote:
>
> Le Thu, 5 May 2022 14:43:54 -0500,
> Rob Herring a écrit :
>
> > On Wed, May 04, 2022 at 05:40:32PM +0200, Clément Léger wrote:
> > > Add functions which allows to create and free nodes.
> > >
> > > Signed-off-by: Clément Léger
> > > ---
>
On 5/9/22 01:46, Baolin Wang wrote:
>
>
> On 5/9/2022 1:46 PM, Christophe Leroy wrote:
>>
>>
>> Le 08/05/2022 à 15:09, Baolin Wang a écrit :
>>>
>>>
>>> On 5/8/2022 7:09 PM, Muchun Song wrote:
On Sun, May 08, 2022 at 05:36:39PM +0800, Baolin Wang wrote:
> It is incorrect to use
The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
default linker of the compiler is used instead of the linker requested
by the builder.
$ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
...
$ llvm-readelf -p .comment
Hi all,
This series is an alternative to the one proposed by Nick before the
PowerPC vDSO unification in commit fd1feade75fb ("powerpc/vdso: Merge
vdso64 and vdso32 into a single directory"):
https://lore.kernel.org/20200901222523.1941988-1-ndesaulni...@google.com/
Normally, we try to make
When linking vdso{32,64}.so.dbg with ld.lld, there is a warning about
not finding _start for the starting address:
ld.lld: warning: cannot find entry symbol _start; not setting start address
ld.lld: warning: cannot find entry symbol _start; not setting start address
Looking at GCC + GNU ld,
On 5/8/22 02:36, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When migrating a hugetlb page, we
Hi Alexey,
On Mon, May 09, 2022 at 05:42:59PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 5/9/22 15:18, Alexey Kardashevskiy wrote:
> >
> >
> > On 5/4/22 07:21, Nick Desaulniers wrote:
> > > On Thu, Apr 28, 2022 at 11:46 PM Alexey Kardashevskiy
> > > wrote:
> > > >
> > > > This enables
On 5/8/22 02:36, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When unmapping a hugetlb page, we
On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
>
> On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
>> The panic notifier infrastructure executes registered callbacks when
>> a panic event happens - such callbacks are executed in atomic context,
>> with interrupts and preemption
On 05/05/2022 15:55, Hari Bathini wrote:
> [...]
> The change looks good. I have tested it on an LPAR (ppc64).
>
> Reviewed-by: Hari Bathini
>
Hi Michael. do you think it's possible to add this one to powerpc/next
(or something like that), or do you prefer a V2 with his tag?
Thanks,
Hey Hatayma, thanks for your great analysis and no need for apologies!
I'll comment/respond properly inline below, just noticing here that I've
CCed Mark and Marc (from the ARM64 perspective), Michael (Hyper-V
perspective) and Hari (PowerPC perspective), besides the usual suspects
as Petr,
On Mon, May 09, 2022 at 02:24:40PM -0700, Nick Desaulniers wrote:
> On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor wrote:
> >
> > The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> > default linker of the compiler is used instead of the linker requested
> > by the
[resending due to mailing list bounces from a large plain text attachment...]
On Mon, May 09, 2022 at 01:24:33PM +0900, Masahiro Yamada wrote:
> On Mon, May 9, 2022 at 4:09 AM Masahiro Yamada wrote:
> >
> > This is the third batch of cleanups in this development cycle.
> >
> > Major changes in
On Mon, May 09, 2022 at 02:58:09PM -0700, Nick Desaulniers wrote:
> On Mon, May 9, 2022 at 2:47 PM Nathan Chancellor wrote:
> >
> > On Mon, May 09, 2022 at 02:24:40PM -0700, Nick Desaulniers wrote:
> > > On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor
> > > wrote:
> > > >
> > > > The PowerPC
On 27/04/2022 19:48, Guilherme G. Piccoli wrote:
> In the panic path we have a list of functions to be called, the panic
> notifiers - such callbacks perform various actions in the machine's
> last breath, and sometimes users want them to run before kdump. We
> have the parameter
Sorry for the delayed response. Unfortunately, I had 10 days holidays
until yesterday...
> .../admin-guide/kernel-parameters.txt | 42 ++-
> include/linux/panic_notifier.h| 1 +
> kernel/kexec_core.c | 8 +-
> kernel/panic.c
On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
>
> But there is also an odd set of architecture calls
Hi
On 09/05/2022 14:09, Guilherme G. Piccoli wrote:
On 28/04/2022 05:11, Suzuki K Poulose wrote:
Hi Guilherme,
On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic
On 09/05/2022 13:14, Suzuki K Poulose wrote:
> [...]>
> I have queued this to coresight/next.
>
> Thanks
> Suzuki
Thanks a lot Suzuki!
On Mon, May 09, 2022 at 10:31:14PM +1000, Michael Ellerman wrote:
> Embarrassingly, we have another copy of the logic, used in the C
> versions, they need updating too:
Oops, thanks for finding that.
> With that added it seems to be working correctly for me.
>
> Acked-by: Michael Ellerman
On 5/9/2022 1:46 PM, Christophe Leroy wrote:
Le 08/05/2022 à 15:09, Baolin Wang a écrit :
On 5/8/2022 7:09 PM, Muchun Song wrote:
On Sun, May 08, 2022 at 05:36:39PM +0800, Baolin Wang wrote:
It is incorrect to use ptep_clear_flush() to nuke a hugetlb page
table when unmapping or
- Align c_cc defines.
- Remove extra newlines.
- Realign & adjust number of leading zeros.
- Reorder c_cflag defines to ascending order
- Make comment ending shorted (=remove period and one extra space from
the comments in mips).
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
On 5/10/2022 12:04 PM, Andrew Morton wrote:
On Tue, 10 May 2022 11:45:57 +0800 Baolin Wang
wrote:
Hi,
Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
use ptep_clear_flush() and set_pte_at() to nuke the page table entry
and remap it, and this is incorrect for
_pmem(E)
pseries_rng(E) papr_scm(E) libnvdimm(E) vmx_crypto(E) ext4(E) mbcache(E)
jbd2(E) sd_mod(E) t10_pi(E) crc64_rocksoft(E) crc64(E) sg(E) ibmvscsi(E)
ibmveth(E) scsi_transport_srp(E) fuse(E) [last unloaded: scsi_debug]
[ 1537.084056] CPU: 10 PID: 970489 Comm: dmsetup Tainted: G
On 5/10/2022 4:02 AM, Mike Kravetz wrote:
On 5/9/22 01:46, Baolin Wang wrote:
On 5/9/2022 1:46 PM, Christophe Leroy wrote:
Le 08/05/2022 à 15:09, Baolin Wang a écrit :
On 5/8/2022 7:09 PM, Muchun Song wrote:
On Sun, May 08, 2022 at 05:36:39PM +0800, Baolin Wang wrote:
It is
On 5/10/2022 12:41 AM, Peter Xu wrote:
On Fri, May 06, 2022 at 12:07:13PM -0700, Mike Kravetz wrote:
On 5/3/22 03:03, Gerald Schaefer wrote:
On Tue, 3 May 2022 10:19:46 +0800
Baolin Wang wrote:
On 5/2/2022 10:02 PM, Gerald Schaefer wrote:
[...]
Please see previous code, we'll use the
On Sat, May 07, 2022 at 02:22:43PM +0900, Masahiro Yamada wrote:
> When I refactored this Makefile, I accidentally changed the CONFIG
> option.
>
> Fixes: b52455a73db9 ("crypto: vmx - Align the short log with Makefile
> cleanups")
> Reported-by: kernel test robot
> Signed-off-by: Masahiro
It is incorrect to use ptep_clear_flush() to nuke a hugetlb page
table when unmapping or migrating a hugetlb page, and will change
to use huge_ptep_clear_flush() instead in the following patches.
So this is a preparation patch, which changes the huge_ptep_clear_flush()
to return the original pte
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When migrating a hugetlb page, we will get the relevant page table
entry by
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When unmapping a hugetlb page, we will get the relevant page table
entry by
Hi,
Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
use ptep_clear_flush() and set_pte_at() to nuke the page table entry
and remap it, and this is incorrect for CONT-PTE or CONT-PMD size hugetlb
page, which will cause potential data consistent issue. This patch set
will
On Tue, 10 May 2022 11:45:57 +0800 Baolin Wang
wrote:
> Hi,
>
> Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
> use ptep_clear_flush() and set_pte_at() to nuke the page table entry
> and remap it, and this is incorrect for CONT-PTE or CONT-PMD size hugetlb
> page,
49 matches
Mail list logo
