There is a spelling mistake in a perror message. Fix it.
Signed-off-by: Colin Ian King
---
tools/testing/selftests/powerpc/ptrace/core-pkey.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/ptrace/core-pkey.c
b/tools/testing/selftests/powerpc/
在 2022/10/21 PM12:41, Luck, Tony 写道:
>>> When we do return to user mode the task is going to be busy servicing
>>> a SIGBUS ... so shouldn't try to touch the poison page before the
>>> memory_failure() called by the worker thread cleans things up.
>>
>> What about an RT process on a busy system?
On Wed 2022-10-19 17:01:32, John Ogness wrote:
> Replace (console->flags & CON_ENABLED) usage with console_is_enabled().
>
> Signed-off-by: John Ogness
> ---
> drivers/tty/hvc/hvc_console.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/hvc/hvc_console.c b/
>> But maybe it is some RMW instruction ... then, if all the above options
>> didn't happen ... we
>> could get another machine check from the same address. But then we just
>> follow the usual
>> recovery path.
> Let assume the instruction that cause the COW is in the 63/64 case, aka,
> it is
On Wed, Oct 05, 2022 at 06:29:45PM +0300, Andy Shevchenko wrote:
> One more user outside of GPIO library and pin control folders needs
> to be updated to use fwnode instead of of_node. To make this easier
> introduce a helper in property.h and convert the user.
>
> Note, the helper will be useful
On Mon, Oct 17, 2022 at 11:08:35PM -0700, Christoph Hellwig wrote:
> > +#if IS_ENABLED(CONFIG_EEH) && IS_ENABLED(CONFIG_VFIO_IOMMU_SPAPR_TCE)
> > #include
> > #endif
> >
> > @@ -689,7 +689,7 @@ void vfio_pci_core_close_device(struct vfio_device
> > *core_vdev)
> > vdev->sriov_pf_c
Part 1 deals with the process that triggered the copy on write
fault with a store to a shared read-only page. That process is
send a SIGBUS with the usual machine check decoration to specify
the virtual address of the lost page, together with the scope.
Part 2 sets up to asynchronously take the pa
If the kernel is copying a page as the result of a copy-on-write
fault and runs into an uncorrectable error, Linux will crash because
it does not have recovery code for this case where poison is consumed
by the kernel.
It is easy to set up a test case. Just inject an error into a private
page, for
Cannot call memory_failure() directly from the fault handler because
mmap_lock (and others) are held.
It is important, but not urgent, to mark the source page as h/w poisoned
and unmap it from other tasks.
Use memory_failure_queue() to request a call to memory_failure() for the
page with the erro
Hey everyone,
Here's the second and final tranche of tree-wide conversions to get
random integer handling a bit tamer. It's predominantly another
Coccinelle-based patchset.
First we s/prandom_u32_max/get_random_u32_below/, since the former is
just a deprecated alias for the latter. Then in the ne
With no more users left, we can finally remove this function. Its
replacement is get_random_u32_below().
Signed-off-by: Jason A. Donenfeld
---
include/linux/prandom.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index 1f4a0de7b019..82
This is a simple mechanical transformation done by:
@@
expression E;
@@
- prandom_u32_max(E)
+ get_random_u32_below(E)
Signed-off-by: Jason A. Donenfeld
---
arch/arm/kernel/process.c | 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/loongarch/kernel/proces
These cases were done with this Coccinelle:
@@
expression E;
identifier I;
@@
- do {
...
- I = get_random_u32();
...
- } while (I > E);
+ I = get_random_u32_below(E + 1);
@@
expression E;
identifier I;
@@
- do {
...
- I = get_random_u32();
...
- } while (
These cases were done with this Coccinelle:
@@
expression H;
expression L;
@@
- (get_random_u32_below(H) + L)
+ get_random_u32_between(L, H + L)
And then subsequently cleaned up by hand, with several automatic cases
rejected if it didn't make sense contextually.
Signed-off-by: Jason A. Donenfeld
Now that we have get_random_u32_below(), it's trivial to make inline
helpers to compute get_random_u32_above() and get_random_u32_between(),
which will help clean up open coded loops and manual computations
throughout the tree.
Signed-off-by: Jason A. Donenfeld
---
include/linux/random.h | 24 ++
On Fri, Oct 21, 2022 at 09:43:59PM -0400, Jason A. Donenfeld wrote:
> This is a simple mechanical transformation done by:
>
> @@
> expression E;
> @@
> - prandom_u32_max(E)
> + get_random_u32_below(E)
>
> Signed-off-by: Jason A. Donenfeld
I wish this patchset had included "random: use rejection
On Fri, 21 Oct 2022 21:43:58 -0400 Jason A. Donenfeld wrote:
> Since get_random_u32_below() sits in my random.git tree, these patches
> too will flow through that same tree.
How big is it? Can you provide a stable branch to pull in the new
helpers and then everyone will be able to apply the patch
On Fri, Oct 21, 2022 at 08:55:22PM -0700, Jakub Kicinski wrote:
> On Fri, 21 Oct 2022 21:43:58 -0400 Jason A. Donenfeld wrote:
> > Since get_random_u32_below() sits in my random.git tree, these patches
> > too will flow through that same tree.
>
> How big is it? Can you provide a stable branch to
Delete the redundant word 'the'.
Signed-off-by: wangjianli
---
arch/powerpc/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index ee0433809621..ab786da8c30b 100644
--- a/arch/powerpc/kernel/process
Commit a4cb3651a1743 ("powerpc/64s/interrupt: Fix lost interrupts when
returning to soft-masked context") fixed the problem of pending irqs
pending cleared when clearing the HARD_DIS bit, but then it didn't clear
the bit at all. This change clears HARD_DIS without affecting other bits
in the mask.
On Sat, 22 Oct 2022 00:23:00 -0400 Jason A. Donenfeld wrote:
> > How big is it? Can you provide a stable branch to pull in the new
> > helpers and then everyone will be able to apply the patches to their
> > subsystem?
>
> It's a patch. But what you suggest sounds crazy to me. Supply some
> bra
On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote:
> But whatever. I mean - hopefully there aren't any conflicts in the ~50
> networking files you touch. I just wish that people didn't pipe up with
> the tree wide changes right after the merge window. Feels like the
> worst possible ti
On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote:
> On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote:
> > But whatever. I mean - hopefully there aren't any conflicts in the ~50
> > networking files you touch. I just wish that people didn't pipe up with
> > the tree wide cha
23 matches
Mail list logo
