On 05. 11. 20, 8:04, Christophe Leroy wrote:
Le 04/11/2020 à 20:35, Lee Jones a écrit :
Fixes the following W=1 kernel build warning(s):
drivers/tty/serial/pmac_zilog.h:365:58: warning: variable ‘garbage’
set but not used [-Wunused-but-set-variable]
Explain how you are fixing this
Le 04/11/2020 à 20:35, Lee Jones a écrit :
Fixes the following W=1 kernel build warning(s):
drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for
‘hvc_vio_init_early’ [-Wmissing-prototypes]
385 | void __init hvc_vio_init_early(void)
| ^~
Cc: Michael
Le 04/11/2020 à 20:35, Lee Jones a écrit :
Fixes the following W=1 kernel build warning(s):
drivers/tty/serial/pmac_zilog.h:365:58: warning: variable ‘garbage’ set but
not used [-Wunused-but-set-variable]
Explain how you are fixing this warning.
Setting __always_unused is usually not
From: Daniel Axtens
Add uaccess blocks and use the 'unsafe' versions of functions doing user
access where possible to reduce the number of times uaccess has to be
opened/closed.
There is no 'unsafe' version of copy_siginfo_to_user, so move it
slightly to allow for a "longer" uaccess block.
Previously setup_sigcontext() performed a costly KUAP switch on every
uaccess operation. These repeated uaccess switches cause a significant
drop in signal handling performance.
Rewrite setup_sigcontext() to assume that a userspace write access window
is open. Replace all uaccess functions with
Implement raw_copy_from_user_allowed() which assumes that userspace read
access is open. Use this new function to implement raw_copy_from_user().
Finally, wrap the new function to follow the usual "unsafe_" convention
of taking a label argument. The new raw_copy_from_user_allowed() calls
Previously restore_sigcontext() performed a costly KUAP switch on every
uaccess operation. These repeated uaccess switches cause a significant
drop in signal handling performance.
Rewrite restore_sigcontext() to assume that a userspace read access
window is open. Replace all uaccess functions
From: Daniel Axtens
Add uaccess blocks and use the 'unsafe' versions of functions doing user
access where possible to reduce the number of times uaccess has to be
opened/closed.
Signed-off-by: Daniel Axtens
Co-developed-by: Christopher M. Riedl
Signed-off-by: Christopher M. Riedl
---
As reported by Anton, there is a large penalty to signal handling
performance on radix systems using KUAP. The signal handling code
performs many user access operations, each of which needs to switch the
KUAP permissions bit to open and then close user access. This involves a
costly 'mtspr'
Similar to commit 1c32940f5220 ("powerpc/signal32: Remove ifdefery in
middle of if/else") for PPC32, remove the messy ifdef. Unlike PPC32, the
ifdef cannot be removed entirely since the uc_transact member of the
sigframe depends on CONFIG_PPC_TRANSACTIONAL_MEM=y.
Signed-off-by: Christopher M.
There are non-inline functions which get called in setup_sigcontext() to
save register state to the thread struct. Move these functions into a
separate prepare_setup_sigcontext() function so that
setup_sigcontext() can be refactored later into an "unsafe" version
which assumes an open uaccess
Reuse the "safe" implementation from signal.c except for calling
unsafe_copy_from_user() to copy into a local buffer. Unlike the
unsafe_copy_{vsx,fpr}_to_user() functions the "copy from" functions
cannot use unsafe_get_user() directly to bypass the local buffer since
doing so significantly reduces
David Hildenbrand writes:
> Let's use alloc_contig_pages() for allocating memory and remove the
> linear mapping manually via arch_remove_linear_mapping(). Mark all pages
> PG_offline, such that they will definitely not get touched - e.g.,
> when hibernating. When freeing memory, try to revert
Lee Jones writes:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for
> ‘hvc_vio_init_early’ [-Wmissing-prototypes]
> 385 | void __init hvc_vio_init_early(void)
> | ^~
>
> Cc: Michael Ellerman
> Cc:
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 293501
--> https://bugzilla.kernel.org/attachment.cgi?id=293501=edit
dmesg (5.9.3 + KASAN, PowerMac G4 DP)
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 293499
--> https://bugzilla.kernel.org/attachment.cgi?id=293499=edit
kernel .config (5.9.3 + KASAN, PowerMac G4 DP)
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 293497
--> https://bugzilla.kernel.org/attachment.cgi?id=293497=edit
dmesg (5.10-rc1 + patch reverted + KASAN, PowerMac G4 DP)
--
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 293495
--> https://bugzilla.kernel.org/attachment.cgi?id=293495=edit
kernel .config (5.10-rc1 + KASAN, PowerMac G4 DP)
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #3)
> Could you test whether CONFIG_KASAN works:
> - on 5.10-rc1 with that commit reverted ?
> - on 5.9 ?
KASAN works in both cases. I'll attach
Fixes the following W=1 kernel build warning(s):
drivers/tty/hvc/hvc_opal.c:106:6: warning: no previous prototype for
‘hvc_opal_hvsi_hangup’ [-Wmissing-prototypes]
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/tty/serial/pmac_zilog.h:365:58: warning: variable ‘garbage’ set but
not used [-Wunused-but-set-variable]
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/tty/hvc/hvc_vio.c:181:6: warning: no previous prototype for
‘hvterm_hvsi_hangup’ [-Wmissing-prototypes]
181 | void hvterm_hvsi_hangup(struct hvc_struct *hp, int data)
| ^~
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for
‘hvc_vio_init_early’ [-Wmissing-prototypes]
385 | void __init hvc_vio_init_early(void)
| ^~
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (36):
tty: serdev: core: Remove unused variable 'dummy'
tty: serdev: core: Provide missing description for 'owner'
tty:
On Tue, 3 Nov 2020 15:10:43 +0100
Petr Mladek wrote:
> BTW: What is actually the purpose of paranoid_test, please?
>
> It prevents nested ftrace_record_recursion() calls on the same CPU
> (recursion, nesting from IRQ, NMI context).
>
> Parallel calls from different CPUs are still possible:
>
From: "Steven Rostedt (VMware)"
If a ftrace callback does not supply its own recursion protection and
does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will
make a helper trampoline to do so before calling the callback instead of
just calling the callback directly.
The default
r_conf.strength;
chip->ecc.size = nand->ecc.user_conf.step_size;
---
Thanks
Christophe
Sorry for introducing this issue, I didn't had the time to send the
Fixes PR yet but I think this issue has been solved already. Could
you please try with a recent linux-next?
Sorry, same
On 11/3/20 5:20 PM, Mike Rapoport wrote:
From: Mike Rapoport
Subject should have "on DEBUG_PAGEALLOC" ?
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some
On 2020-11-04 01:06, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at
drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter
or member
On 2020-11-04 05:38, Andrew Lunn wrote:
On Wed, Nov 04, 2020 at 09:06:07AM +, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at
drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
Hi Christophe,
Christophe Leroy wrote on Wed, 04 Nov
2020 18:33:53 +0100:
> Hi Miquel,
>
> I'm unable to boot 5.10-rc1 on my boards. I get the following error:
>
> [4.125811] nand: device found, Manufacturer ID: 0xad, Chip ID: 0x76
> [4.131992] nand: Hynix NAND 64MiB 3,3V 8-bit
> [
On 11/3/20 5:20 PM, Mike Rapoport wrote:
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() that will explicitly use
On 11/3/20 5:20 PM, Mike Rapoport wrote:
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded
Hi Miquel,
I'm unable to boot 5.10-rc1 on my boards. I get the following error:
[4.125811] nand: device found, Manufacturer ID: 0xad, Chip ID: 0x76
[4.131992] nand: Hynix NAND 64MiB 3,3V 8-bit
[4.136173] nand: 64 MiB, SLC, erase size: 16 KiB, page size: 512,
OOB size: 16
[
>>> To be sure we are not in front of a long lasting bug, could you try
>>> CONFIG_KASAN=y on v5.9 ?
>>
>> Indeed it started to fail somewhere between v5.6 and v5.7.
>>
>> v5.7 fails early with few messages on the console with reboot, v5.8 and
>> later hang right at bootloader.
>>
>> I'm bisecting
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #3 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Ok, thanks for the verification. I'm still having hard time understand what the
problem can be. That commit sets up at all time the early hash table that was
previously only
On Wed, Nov 04, 2020 at 09:06:08AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function
> parameter or member 'irq' not described in 'gelic_card_interrupt'
>
On Wed, Nov 04, 2020 at 09:06:07AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> from drivers/net/ethernet/ibm/ibmvnic.c:35:
> inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
> drivers/net/ethernet/ibm/ibmvnic.c:1362: warning:
On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> Let's revert what we did in case seomthing goes wrong and we return an
> error.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Rashmica Gupta
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc:
On Wed, Nov 04, 2020 at 02:06:51PM +0200, Mike Rapoport wrote:
> On Wed, Nov 04, 2020 at 10:50:07AM +0100, osalvador wrote:
> > On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> > > Let's revert what we did in case seomthing goes wrong and we return an
> > > error.
> >
> > Dumb
On Wed, Nov 4, 2020 at 4:22 AM Michael Ellerman wrote:
> > +#ifdef __LITTLE_ENDIAN__
>
> As Kees mentioned this should (must?!) match the configured endian.
>
> But I think it would still be better to use the CONFIG symbol, which is
> CONFIG_CPU_LITTLE_ENDIAN.
My attempt here is to be consistent
Use the common INIT_DATA_SECTION rule for the linker script in an effort
to regularize the linker script.
Signed-off-by: Youling Tang
---
arch/powerpc/kernel/vmlinux.lds.S | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
On Wed, Nov 04, 2020 at 10:50:07AM +0100, osalvador wrote:
> On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> > Let's revert what we did in case seomthing goes wrong and we return an
> > error.
>
> Dumb question, but should not we do this for other arches as well?
It seems
On Wed, 28 Oct 2020 11:27:17 -0400, Qian Cai wrote:
> Lockdep complains that a possible deadlock below in
> eeh_addr_cache_show() because it is acquiring a lock with IRQ enabled,
> but eeh_addr_cache_insert_dev() needs to acquire the same lock with IRQ
> disabled. Let's just make
On Wed, 28 Oct 2020 14:23:34 -0400, Qian Cai wrote:
> The call to rcu_cpu_starting() in start_secondary() is not early enough
> in the CPU-hotplug onlining process, which results in lockdep splats as
> follows:
>
> WARNING: suspicious RCU usage
> -
>
With that patch the kernel is working again.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
__put_user_size_allowed() to __put_user_asm_goto()") broke
CLONE_CHILD_SETTID.
Further inspection showed that the put_user() in schedule_tail() was
missing entirely, the store not emitted by the compiler.
<.schedule_tail>:
Christophe Leroy writes:
> Le 03/11/2020 à 14:29, Michael Ellerman a écrit :
>> Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
>> __put_user_size_allowed() to __put_user_asm_goto()") broke
>> CLONE_CHILD_SETTID.
>>
>> Further inspection showed that the put_user() in
YiFei Zhu writes:
> From: YiFei Zhu
>
> To enable seccomp constant action bitmaps, we need to have a static
> mapping to the audit architecture and system call table size. Add these
> for powerpc.
>
> Signed-off-by: YiFei Zhu
> ---
> arch/powerpc/include/asm/seccomp.h | 21
On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> Let's revert what we did in case seomthing goes wrong and we return an
> error.
Dumb question, but should not we do this for other arches as well?
--
Oscar Salvador
SUSE L3
On Thu, Oct 29, 2020 at 05:27:16PM +0100, David Hildenbrand wrote:
> Let's print a warning similar to in arch_add_linear_mapping() instead of
> WARN_ON_ONCE() and eventually crashing the kernel.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Rashmica Gupta
>
Le 03/11/2020 à 22:08, Dmitry Safonov a écrit :
Hi Laurent, Christophe, Michael, all,
On 11/3/20 5:11 PM, Laurent Dufour wrote:
Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
[..]
That seems like it would work for CRIU and make sense in general?
Sorry for the late answer, yes this would
>> To be sure we are not in front of a long lasting bug, could you try
>> CONFIG_KASAN=y on v5.9 ?
>
> Indeed it started to fail somewhere between v5.6 and v5.7.
>
> v5.7 fails early with few messages on the console with reboot, v5.8 and
> later hang right at bootloader.
>
> I'm bisecting now.
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member
'hdr_data' not described in 'build_hdr_data'
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter
or member 'irq' not described in 'gelic_card_interrupt'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter
or member 'ptr' not described
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member
'hdr_field' not described in 'build_hdr_data'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
This is the last set.
Lee Jones (12):
net: usb:
On Wed, Nov 04, 2020 at 12:14:06PM +1100, Michael Ellerman wrote:
> From: Nicholas Piggin
>
> commit d53c3dfb23c45f7d4f910c3a3ca84bf0a99c6143 upstream.
>
> Reading and modifying current->mm and current->active_mm and switching
> mm should be done with irqs off, to prevent races seeing an
58 matches
Mail list logo
