Mimi, James, Jarkko, David,
you remained silent for a whole release cycle.
Is there anything we can do to get this forward?
Thanks,
//richard
Am Dienstag, 13. Februar 2024, 10:59:56 CET schrieb Richard Weinberger:
> Am Montag, 5. Februar 2024, 09:39:07 CET schrieb David Gstir:
>
Am Montag, 5. Februar 2024, 09:39:07 CET schrieb David Gstir:
> Hi,
>
> > On 15.12.2023, at 12:06, David Gstir wrote:
> >
> > This is a revival of the previous patch set submitted by Richard Weinberger:
> > https://lore.kernel.org/linux-integrity/2021061
Am Samstag, 8. Dezember 2018, 07:35:47 CET schrieb Masahiro Yamada:
> x86 maintainers,
>
>
> Ping.
I thought you carry this via your kbuild tree.
That said, I can merge it also via the um tree.
x86 is of course also fine. :-)
>
>
> On Tue, Nov 13, 2018 at 6:48 PM Rich
else echo $(call cc-option,-funit-at-a-time); fi ;)
> +# gcc 4.3.0 needs -funit-at-a-time for extern inline functions.
> +KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
Acked-by: Richard Weinberger
Thanks,
//richard
Joel,
Am Samstag, 3. November 2018, 05:00:38 CET schrieb Joel Fernandes:
> Hi,
> Here is the latest "fast mremap" series. This just a repost with Kirill's
> Acked-bys added. I would like this to be considered for linux -next. I also
> dropped the CONFIG enablement patch for arm64 since I am yet
ck() calls and all
> erase_info->state assignments. While at it, get rid of the
> erase_info->state field, all MTD_ERASE_XXX definitions and the
> mtd_erase_callback() function.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
Reviewed-by: Richard Weinberger <rich...@nod.at>
Thanks,
//richard
e_info->mtd field which was only
> needed to let mtd_erase_callback() get the partition device back.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
Reviewed-by: Richard Weinberger <rich...@nod.at>
Thanks,
//richard
ns
> failure.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
Reviewed-by: Richard Weinberger <rich...@nod.at>
Thanks,
//richard
;
> u_char state;
> - struct erase_info *next;
> };
>
> struct mtd_erase_region_info {
Reviewed-by: Richard Weinberger <rich...@nod.at>
Thanks,
//richard
P;
>
> @@ -961,7 +963,6 @@ int mtd_erase(struct mtd_info *mtd, struct erase_info
> *instr) if (!(mtd->flags & MTD_WRITEABLE))
> return -EROFS;
>
> - instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
> if (!instr->len) {
> inst
Hi!
Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch
this code area.
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> Acked-by: Arnd Bergmann <a...@arndb.de>
Acked-by: Richard Weinberger <rich...@nod.at>
Thanks,
//richard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz
Am 11.06.2015 um 07:43 schrieb Michael Ellerman:
On Fri, 2015-06-05 at 10:16 +0200, Richard Weinberger wrote:
On Fri, Jun 5, 2015 at 6:40 AM, Cyril Bur cyril...@gmail.com wrote:
On Tue, 2015-06-02 at 14:26 +1000, Cyril Bur wrote:
Powerpc powernv platforms allow access to certain system flash
On Fri, Jun 5, 2015 at 6:40 AM, Cyril Bur cyril...@gmail.com wrote:
On Tue, 2015-06-02 at 14:26 +1000, Cyril Bur wrote:
Powerpc powernv platforms allow access to certain system flash devices
through a firmwarwe interface. This change adds an mtd driver for these
flash devices.
Minor updates
Am 20.03.2015 um 16:53 schrieb Laurent Dufour:
Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and
Am 07.12.2014 um 23:07 schrieb Rickard Strandqvist:
Remove the function sys_debug_setcontext() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Please don't blindly trust code analysis tools.
The function you're removing *is* in
Am 08.12.2014 um 00:11 schrieb Rickard Strandqvist:
Hi
Ok, sorry :-(
But I really do not. I've hacked together a script that will scan all
the code for the function, and test builds with some different config
options turned on.
Looks like you did not build a powerpc32 kernel. :-)
FWIW,
Am 07.10.2014 07:28, schrieb Guenter Roeck:
arch/um/kernel/reboot.c| 2 --
Acked-by: Richard Weinberger rich...@nod.at
Thanks,
//richard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
From: Richard Weinberger rich...@nod.at
Use the more generic functions get_signal() signal_setup_done()
for signal delivery.
This inverts also the return codes of setup_*frame() to follow the
kernel convention.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/powerpc/kernel/signal.c
From: Richard Weinberger rich...@nod.at
Use sigsp() instead of the open coded variant.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/powerpc/kernel/signal.c| 10 ++
arch/powerpc/kernel/signal_32.c | 4 ++--
arch/powerpc/kernel/signal_64.c | 2 +-
3 files changed, 5
like overkill for a
single patch.
For the um bits:
Acked-by: Richard Weinberger rich...@nod.at
I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
changes (or changes to other archs) to go via our tree.
I'm not sure what the best approach is if you want to send this via
Make sure to not conflict with the defaults provided
by generic/tlb.h.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Richard Weinberger rich...@nod.at
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Richard Weinberger
It is no longer needed to define them on our own.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Richard Weinberger rich...@nod.at
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Richard Weinberger rich...@nod.at
On 23.04.2012 09:09, Anton Vorontsov wrote:
Traversing the tasks requires holding tasklist_lock, otherwise it
is unsafe.
p.s. However, I'm not sure that calling os_kill_ptraced_process()
in the atomic context is correct. It seem to work, but please
take a closer look.
Signed-off-by: Anton
Am 26.03.2012 21:01, schrieb Richard Weinberger:
If try_module_get() fails, mpc5121_clk_get() might return
a wrong clock.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/powerpc/platforms/512x/clock.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git
[for x86 portion]
The UML part is now fine for me. :-)
Acked-by: Richard Weinberger rich...@nod.at
Thanks,
//richard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Am Donnerstag 02 Juni 2011, 23:04:58 schrieb Eric Paris:
b/arch/um/sys-i386/shared/sysdep/ptrace.h index d50e62e..ef5c310 100644
--- a/arch/um/sys-i386/shared/sysdep/ptrace.h
+++ b/arch/um/sys-i386/shared/sysdep/ptrace.h
@@ -162,6 +162,7 @@ struct syscall_args {
#define UPT_ORIG_SYSCALL(r)
Am Freitag 03 Juni 2011, 01:00:51 schrieb Tony Luck:
But there seems to be another problem.
Why is pt_regs of type void *?
gcc complains:
In file included from include/linux/fsnotify.h:15:0,
from include/linux/security.h:26,
from init/main.c:32:
28 matches
Mail list logo
