Re: [PATCH v3] mm: Avoid unnecessary page fault retires on shared memory types
e.com>, Thomas Gleixner , linux-al...@vger.kernel.org,
Andrew Morton , Vlastimil Babka ,
Richard Henderson , Chris Zankel , Michal
Simek , Thomas Bogendoerfer ,
Parisc List , Max Filippov ,
Linux Kernel Mailing List , Dinh Nguyen
, Palmer Dabbelt , Sven Schnelle
, Borislav Petkov , Johannes Berg
, linuxppc-dev ,
"David S . Miller"
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev"
For csky part.
Acked-by: Guo Ren
On Wed, May 25, 2022 at 7:45 AM Peter Xu wrote:
>
> I observed that for each of the shared file-backed page faults, we're very
> likely to retry one more time for the 1st write fault upon no page. It's
> because we'll need to release the mmap lock for dirty rate limit purpose
> with balance_dirty_pages_ratelimited() (in fault_dirty_shared_page()).
>
> Then after that throttling we return VM_FAULT_RETRY.
>
> We did that probably because VM_FAULT_RETRY is the only way we can return
> to the fault handler at that time telling it we've released the mmap lock.
>
> However that's not ideal because it's very likely the fault does not need
> to be retried at all since the pgtable was well installed before the
> throttling, so the next continuous fault (including taking mmap read lock,
> walk the pgtable, etc.) could be in most cases unnecessary.
>
> It's not only slowing down page faults for shared file-backed, but also add
> more mmap lock contention which is in most cases not needed at all.
>
> To observe this, one could try to write to some shmem page and look at
> "pgfault" value in /proc/vmstat, then we should expect 2 counts for each
> shmem write simply because we retried, and vm event "pgfault" will capture
> that.
>
> To make it more efficient, add a new VM_FAULT_COMPLETED return code just to
> show that we've completed the whole fault and released the lock. It's also
> a hint that we should very possibly not need another fault immediately on
> this page because we've just completed it.
>
> This patch provides a ~12% perf boost on my aarch64 test VM with a simple
> program sequentially dirtying 400MB shmem file being mmap()ed and these are
> the time it needs:
>
> Before: 650.980 ms (+-1.94%)
> After: 569.396 ms (+-1.38%)
>
> I believe it could help more than that.
>
> We need some special care on GUP and the s390 pgfault handler (for gmap
> code before returning from pgfault), the rest changes in the page fault
> handlers should be relatively straightforward.
>
> Another thing to mention is that mm_account_fault() does take this new
> fault as a generic fault to be accounted, unlike VM_FAULT_RETRY.
>
> I explicitly didn't touch hmm_vma_fault() and break_ksm() because they do
> not handle VM_FAULT_RETRY even with existing code, so I'm literally keeping
> them as-is.
>
> Signed-off-by: Peter Xu
> ---
>
> v3:
> - Rebase to akpm/mm-unstable
> - Copy arch maintainers
> ---
> arch/alpha/mm/fault.c | 4
> arch/arc/mm/fault.c | 4
> arch/arm/mm/fault.c | 4
> arch/arm64/mm/fault.c | 4
> arch/csky/mm/fault.c | 4
> arch/hexagon/mm/vm_fault.c| 4
> arch/ia64/mm/fault.c | 4
> arch/m68k/mm/fault.c | 4
> arch/microblaze/mm/fault.c| 4
> arch/mips/mm/fault.c | 4
> arch/nios2/mm/fault.c | 4
> arch/openrisc/mm/fault.c | 4
> arch/parisc/mm/fault.c| 4
> arch/powerpc/mm/copro_fault.c | 5 +
> arch/powerpc/mm/fault.c | 5 +
> arch/riscv/mm/fault.c | 4
> arch/s390/mm/fault.c | 12 +++-
> arch/sh/mm/fault.c| 4
> arch/sparc/mm/fault_32.c | 4
> arch/sparc/mm/fault_64.c | 5 +
> arch/um/kernel/trap.c | 4
> arch/x86/mm/fault.c | 4
> arch/xtensa/mm/fault.c| 4
> include/linux/mm_types.h | 2 ++
> mm/gup.c | 34 +-
> mm/memory.c | 2 +-
> 26 files changed, 138 insertions(+), 3 deletions(-)
>
> diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
> index ec20c1004abf..ef427a6bdd1a 100644
> --- a/arch/alpha/mm/fault.c
> +++ b/arch/alpha/mm/fault.c
> @@ -155,6 +155,10 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
> if (fault_signal_pending(fault, regs))
> return;
>
> + /* The fault is fully completed (including releasing mmap lock) */
> + if (fault & VM_FAULT_COMPLETED)
> + return;
> +
> if (unlikely(fault & VM_FAULT_ERROR)) {
> if (fault & VM_FAULT_OOM)
> goto out_of_memory;
> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
> index dad27e4d69ff..5ca59a482632 100644
> --- a/arch/arc/mm/fault.c
> +++ b/arch/arc/mm/fault.c
> @@ -146,6 +146,10 @@ void do_page_fault(unsigned long address, struct pt_regs
> *regs)
> return;
>
Re: [GIT PULL] Modules fixes for v5.19-rc1
The pull request you sent on Wed, 25 May 2022 14:49:34 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/ > tags/modules-5.19-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ef98f9cfe20d8ca063365d46d4ab2b85eeeb324f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH net-next] eth: de4x5: remove support for Generic DECchip & DIGITAL EtherWORKS PCI/EISA
On Thu, 2022-05-26 at 09:43 +0200, Geert Uytterhoeven wrote: > Hi Ben, > > On Sat, 21 May 2022, Benjamin Herrenschmidt wrote: > > On Wed, 2022-05-18 at 20:13 -0700, Jakub Kicinski wrote: > > > Looks like almost all changes to this driver had been tree-wide > > > refactoring since git era begun. There is one commit from Al > > > 15 years ago which could potentially be fixing a real bug. > > > > > > The driver is using virt_to_bus() and is a real magnet for pointless > > > cleanups. It seems unlikely to have real users. Let's try to shed > > > this maintenance burden. > > > > > > Signed-off-by: Jakub Kicinski > > > > Removing this driver will kill support for some rather old PowerMac > > models (some PowerBooks I think, paulus would know). No objection on my > > part, though. I doubt people still use these things with new kernels > > but ... who knows ? :-) > > Aren't these PCI, and thus working fine with the PCI-only DE2104X > (dc2104x) or TULIP (dc2114x) drivers? > > IIRC, I've initially used the de4x5 driver on Alpha (UDB/Multia) or PPC > (CHRP), but switched to the TULIP driver later (that was before the > dc2104x/dc2114x driver split, hence a lng time ago). I'm pretty sure there were some old Macs who worked with de4x5 and not tulip but I wouldn't rememeber the details and I'm not sure any of this hardware still exist in the field nor matters. Cheers, Ben.
Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote: > I don't mind adding DRM support for BootX displays, but getting the > necessary test HW with a suitable Linux seems to be laborious. Would > a G4 Powerbook work? Probably not unfortunately... it's going to be tricky. I might sitll have some old BootX-based machines somewhere in storage I could try to dig out, but it might not be worth bothering too much... Cheers, Ben.
Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote: > > > The palette handling is useful when using a real Open Firmware > > implementation which tends to boot in 8-bit mode, so without palette > > things will look ... bad. > > > > It's not necessary when using 16/32 bpp framebuffers which is typically > > ... what BootX provides :-) > > Maybe the odd color formats can be tested via qemu. > > I don't mind adding DRM support for BootX displays, but getting the > necessary test HW with a suitable Linux seems to be laborious. Would a > G4 Powerbook work? My point was that it's the non-BootX case that cares about the palette hacks :-) Cheers, Ben.
Re: [PATCH 1/2] locking/lockref: Use try_cmpxchg64 in CMPXCHG_LOOP macro
On Thu, May 26, 2022 at 5:15 AM Michael Ellerman wrote: > > Do you know of a benchmark that shows it up? I tried a few things but > couldn't get lockref_get() to count for more than 1-2%. Heh. 1% for a small instruction sequence that is only handful of instructions and is used in just a couple of places counts as "very hot" for me. I assume you did the natural thing: threaded pathname lookup (with paths being of the longer variety to not be dominated by system call etc costs). Linus
Re: [PATCH 24/30] panic: Refactor the panic path
Hey folks, first of all thanks a lot for the reviews / opinions about this. I imagined that such change would be polemic, and I see I was right heh I'll try to "mix" all the relevant opinions in a single email, since they happened in different responses and even different mail threads. I've looped here the most interested parties based on the feedback received, such as Baoquan (kdump), Hatayama (kdump), Eric (kexec), Mark (arm64), Michael (Hyper-V), Petr (console/printk) and Vitaly (hyper-v / kvm). I hope we can discuss and try to reach some consensus - my apologies in advance for this long message! So, here goes some feedback we received about this change and correlated feedback from arm64 community - my apologies if I missed something important, I've tried to collect the most relevant portions, while keeping the summary "as short" as possible. I'll respond to such feedback below, after the quotes. On 24/05/2022 05:32, Baoquan He wrote: >> [...] >> Firstly, kdump is not always the first thing. In any use case, if kdump >> kernel is not loaded, it's not the first thing at all. Not to mention >> if crash_kexec_post_notifiers is specified. >> [...] >> Changing this will cause regression. During these years, nobody ever doubt >> kdump should execute firstly if crashkernel is reserved and kdump kernel is >> loaded. That's not saying we can't change >> this, but need a convincing justification. >> [...] >> Secondly, even with the notifiers' split, we can't guarantee people will >> absolutely add notifiers into right list in the future. Letting kdump >> execute behind lists by default will put kdump into risk. >> [...] >> As for Hyper-V, if it enforces to terminate VMbus connection, no matter >> it's kdump or not, why not taking it out of panic notifiers list and >> execute it before kdump unconditionally. On 24/05/2022 05:01, Petr Mladek wrote: >> [...] >> Anyway, I see four possible solutions: >> >> 1. The most conservative approach is to keep the current behavior >> and call kdump first by default. >> >> 2. A medium conservative approach to change the default default >> behavior and call hypervisor and eventually the info notifiers >> before kdump. There still would be the possibility to call kdump >> first by the command line parameter. >> >> 3. Remove the possibility to call kdump first completely. It would >> assume that all the notifiers in the info list are super safe >> or that they make kdump actually more safe. >> >> 4. Create one more notifier list for operations that always should >> be called before crash_dump. >> >> Regarding the extra notifier list (4th solution). It is not clear to >> me whether it would be always called even before hypervisor list or >> when kdump is not enabled. We must not over-engineer it. >> >> 2nd proposal looks like a good compromise. But maybe we could do >> this change few releases later. The notifiers split is a big >> change on its own. On 24/05/2022 07:18, Baoquan He wrote: >>[...] >> I would vote for 1 or 4 without any hesitation, and prefer 4. I ever >> suggest the variant of solution 4 in v1 reviewing. That's taking those >> notifiers out of list and enforcing to execute them before kdump. E.g >> the one on HyperV to terminate VMbus connection. Maybe solution 4 is >> better to provide a determinate way for people to add necessary code >> at the earliest part. >> [...] >>> >>> Regarding the extra notifier list (4th solution). It is not clear to >>> me whether it would be always called even before hypervisor list or >>> when kdump is not enabled. We must not over-engineer it. >> >> One thing I would like to notice is, no matter how perfect we split the >> lists this time, we can't gurantee people will add notifiers reasonablly >> in the future. And people from different sub-component may not do >> sufficient investigation and add them to fulfil their local purpose. >> >> The current panic notifers list is the best example. Hyper-V actually >> wants to run some necessary code before kdump, but not all of them, they >> just add it, ignoring the original purpose of >> crash_kexec_post_notifiers. I guess they do like this just because it's >> easy to do, no need to bother changing code in generic place. >> >> Solution 4 can make this no doubt, that's why I like it better. >> [...] >> As I replied to Guilherme, solution 2 will cause regression if not >> calling kdump firstly. Solution 3 leaves people space to make mistake, >> they could add nontifier into wrong list. >> >> I would like to note again that the panic notifiers are optional to run, >> while kdump is expectd once loaded, from the original purpose. I guess >> people I know will still have this thought, e.g Hatayama, Masa, they are >> truly often use panic notifiers like this on their company's system. On 24/05/2022 11:44, Eric W. Biederman wrote: > [...] > Unfortunately I am also very grouchy. > > Notifiers before kexec on panic are
Re: [PATCH 1/2] locking/lockref: Use try_cmpxchg64 in CMPXCHG_LOOP macro
On Thu, May 26, 2022 at 10:14:59PM +1000, Michael Ellerman wrote: > Linus Torvalds writes: > > On Wed, May 25, 2022 at 7:40 AM Uros Bizjak wrote: > >> > >> Use try_cmpxchg64 instead of cmpxchg64 in CMPXCHG_LOOP macro. > >> x86 CMPXCHG instruction returns success in ZF flag, so this > >> change saves a compare after cmpxchg (and related move instruction > >> in front of cmpxchg). The main loop of lockref_get improves from: > > > > Ack on this one regardless of the 32-bit x86 question. > > > > HOWEVER. > > > > I'd like other architectures to pipe up too, because I think right now > > x86 is the only one that implements that "arch_try_cmpxchg()" family > > of operations natively, and I think the generic fallback for when it > > is missing might be kind of nasty. > > > > Maybe it ends up generating ok code, but it's also possible that it > > just didn't matter when it was only used in one place in the > > scheduler. > > This patch seems to generate slightly *better* code on powerpc. > > I see one register-to-register move that gets shifted slightly later, so > that it's skipped on the path that returns directly via the SUCCESS > case. FWIW, I see the same on arm64; a register-to-register move gets moved out of the success path. That changes the register allocation, and resulting in one fewer move, but otherwise the code generation is the same. Thanks, Mark.
Re: [PATCH 1/2] locking/lockref: Use try_cmpxchg64 in CMPXCHG_LOOP macro
Linus Torvalds writes: > On Wed, May 25, 2022 at 7:40 AM Uros Bizjak wrote: >> >> Use try_cmpxchg64 instead of cmpxchg64 in CMPXCHG_LOOP macro. >> x86 CMPXCHG instruction returns success in ZF flag, so this >> change saves a compare after cmpxchg (and related move instruction >> in front of cmpxchg). The main loop of lockref_get improves from: > > Ack on this one regardless of the 32-bit x86 question. > > HOWEVER. > > I'd like other architectures to pipe up too, because I think right now > x86 is the only one that implements that "arch_try_cmpxchg()" family > of operations natively, and I think the generic fallback for when it > is missing might be kind of nasty. > > Maybe it ends up generating ok code, but it's also possible that it > just didn't matter when it was only used in one place in the > scheduler. This patch seems to generate slightly *better* code on powerpc. I see one register-to-register move that gets shifted slightly later, so that it's skipped on the path that returns directly via the SUCCESS case. So LGTM. > The lockref_get() case can be quite hot under some loads, it would be > sad if this made other architectures worse. Do you know of a benchmark that shows it up? I tried a few things but couldn't get lockref_get() to count for more than 1-2%. cheers
Re: [RFC PATCH 1/4] objtool: Add --mnop as an option to --mcount
Peter Zijlstra wrote: On Tue, May 24, 2022 at 04:01:48PM +0530, Naveen N. Rao wrote: We need to know for sure either way. Nop'ing out the _mcount locations at boot allows us to discover existing long branch trampolines. If we want to avoid it, we need to note down those locations during build time. Do you have a different approach in mind? If you put _mcount in a separate section then the compiler cannot tell where it is and is forced to always emit a long branch trampoline. Does that help? That's an interesting thought. Depending on the type of trampoline the compiler emits, I might be able to use this approach. We will still need objtool on powerpc so that we can note down those trampoline locations. Thanks, Naveen
Re: [PATCH] kexec_file: Drop weak attribute from arch_kexec_apply_relocations[_add]
Andrew Morton wrote: On Fri, 20 May 2022 14:25:05 -0500 "Eric W. Biederman" wrote: > I am not strongly against taking off __weak, just wondering if there's > chance to fix it in recordmcount, and the cost comparing with kernel fix; > except of this issue, any other weakness of __weak. Noticed Andrew has > picked this patch, as a witness of this moment, raise a tiny concern. I just don't see what else we can realistically do. I think converting all of the kexec __weaks to use the ifdef approach makes sense, if only because kexec is now using two different styles. But for now, I'll send Naveen's v2 patch in to Linus to get us out of trouble. Thanks! I'm thinking that we should add cc:stable to that patch as well, to reduce the amount of problems which people experience when using newer binutils on older kernels? Yes, please. I missed tagging this for stable. It looks like this is applicable all the way back to v4.9 (though I haven't tested if recordmcount fails in the same manner with those older kernel levels). I will post backports once this gets into linus' tree. - Naveen
Re: [PATCH -next v4 3/7] arm64: add support for machine check error safe
On Thu, May 26, 2022 at 11:36:41AM +0800, Tong Tiangen wrote:
>
>
> 在 2022/5/25 16:30, Mark Rutland 写道:
> > On Thu, May 19, 2022 at 02:29:54PM +0800, Tong Tiangen wrote:
> > >
> > >
> > > 在 2022/5/13 23:26, Mark Rutland 写道:
> > > > On Wed, Apr 20, 2022 at 03:04:14AM +, Tong Tiangen wrote:
> > > > > During the processing of arm64 kernel hardware memory
> > > > > errors(do_sea()), if
> > > > > the errors is consumed in the kernel, the current processing is panic.
> > > > > However, it is not optimal.
> > > > >
> > > > > Take uaccess for example, if the uaccess operation fails due to memory
> > > > > error, only the user process will be affected, kill the user process
> > > > > and isolate the user page with hardware memory errors is a better
> > > > > choice.
> > > >
> > > > Conceptually, I'm fine with the idea of constraining what we do for a
> > > > true uaccess, but I don't like the implementation of this at all, and I
> > > > think we first need to clean up the arm64 extable usage to clearly
> > > > distinguish a uaccess from another access.
> > >
> > > OK,using EX_TYPE_UACCESS and this extable type could be recover, this is
> > > more reasonable.
> >
> > Great.
> >
> > > For EX_TYPE_UACCESS_ERR_ZERO, today we use it for kernel accesses in a
> > > couple of cases, such as
> > > get_user/futex/__user_cache_maint()/__user_swpX_asm(),
> >
> > Those are all user accesses.
> >
> > However, __get_kernel_nofault() and __put_kernel_nofault() use
> > EX_TYPE_UACCESS_ERR_ZERO by way of __{get,put}_mem_asm(), so we'd need to
> > refactor that code to split the user/kernel cases higher up the callchain.
> >
> > > your suggestion is:
> > > get_user continues to use EX_TYPE_UACCESS_ERR_ZERO and the other cases use
> > > new type EX_TYPE_FIXUP_ERR_ZERO?
> >
> > Yes, that's the rough shape. We could make the latter
> > EX_TYPE_KACCESS_ERR_ZERO
> > to be clearly analogous to EX_TYPE_UACCESS_ERR_ZERO, and with that I
> > susepct we
> > could remove EX_TYPE_FIXUP.
> >
> > Thanks,
> > Mark.
> According to your suggestion, i think the definition is like this:
>
> #define EX_TYPE_NONE0
> #define EX_TYPE_FIXUP 1--> delete
> #define EX_TYPE_BPF 2
> #define EX_TYPE_UACCESS_ERR_ZERO3
> #define EX_TYPE_LOAD_UNALIGNED_ZEROPAD 4
> #define EX_TYPE_UACCESS xx --> add
> #define EX_TYPE_KACCESS_ERR_ZEROxx --> add
> [The value defined by the macro here is temporary]
Almost; you don't need to add EX_TYPE_UACCESS here, as you can use
EX_TYPE_UACCESS_ERR_ZERO for that.
We already have:
| #define _ASM_EXTABLE_UACCESS_ERR(insn, fixup, err)\
| _ASM_EXTABLE_UACCESS_ERR_ZERO(insn, fixup, err, wzr)
... and we can add:
| #define _ASM_EXTABLE_UACCESS(insn, fixup) \
| _ASM_EXTABLE_UACCESS_ERR_ZERO(insn, fixup, wzr, wzr)
... and maybe we should use 'xzr' rather than 'wzr' for clarity.
> There are two points to modify:
>
> 1、_get_kernel_nofault() and __put_kernel_nofault() using
> EX_TYPE_KACCESS_ERR_ZERO, Other positions using EX_TYPE_UACCESS_ERR_ZERO
> keep unchanged.
That sounds right to me. This will require refactoring __raw_{get,put}_mem()
and __{get,put}_mem_asm().
> 2、delete EX_TYPE_FIXUP.
>
> There is no doubt about others. As for EX_TYPE_FIXUP, I think it needs to be
> retained, _cond_extable(EX_TYPE_FIXUP) is still in use in assembler.h.
We use _cond_extable for cache maintenance uaccesses, so those should be moved
over to to EX_TYPE_UACCESS_ERR_ZERO. We can rename _cond_extable to
_cond_uaccess_extable for clarity.
That will require restructuring asm-extable.h a bit. If that turns out to be
painful I'm happy to take a look.
Thanks,
Mark.
dangling pointer to '__str' error on ppc64_defconfig, GCC 12.1.0
Hi everyone,
Attempting to build ppc64_defconfig kernel with powerpc64-unknown-linux-gnu
(GCC 12.1.0) on v5.18, I got build error on ftrace.o:
CC arch/powerpc/kernel/trace/ftrace.o
CC init/init_task.o
In file included from ./include/asm-generic/bug.h:22,
from ./arch/powerpc/include/asm/bug.h:156,
from ./include/linux/bug.h:5,
from ./include/linux/thread_info.h:13,
from ./include/asm-generic/preempt.h:5,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:55,
from arch/powerpc/kernel/trace/ftrace.c:16:
arch/powerpc/kernel/trace/ftrace.c: In function 'ftrace_modify_code':
./include/linux/printk.h:446:44: error: using a dangling pointer to '__str'
[-Werror=dangling-pointer=]
446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
|^
./include/linux/printk.h:418:17: note: in definition of macro
'printk_index_wrap'
418 | _p_func(_fmt, ##__VA_ARGS__);
\
| ^~~
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
| ^~
arch/powerpc/kernel/trace/ftrace.c:75:17: note: in expansion of macro 'pr_err'
75 | pr_err("%p: replaced (%s) != old (%s)",
| ^~
In file included from ./arch/powerpc/include/asm/code-patching.h:14,
from arch/powerpc/kernel/trace/ftrace.c:26:
./arch/powerpc/include/asm/inst.h:156:14: note: '__str' declared here
156 | char __str[PPC_INST_STR_LEN]; \
| ^
./include/linux/printk.h:418:33: note: in expansion of macro 'ppc_inst_as_str'
418 | _p_func(_fmt, ##__VA_ARGS__);
\
| ^~~
./include/linux/printk.h:446:26: note: in expansion of macro 'printk_index_wrap'
446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ^
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
| ^~
arch/powerpc/kernel/trace/ftrace.c:75:17: note: in expansion of macro 'pr_err'
75 | pr_err("%p: replaced (%s) != old (%s)",
| ^~
arch/powerpc/kernel/trace/ftrace.c: In function '__ftrace_make_nop_kernel':
./include/linux/printk.h:446:44: error: using a dangling pointer to '__str'
[-Werror=dangling-pointer=]
446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
|^
./include/linux/printk.h:418:17: note: in definition of macro
'printk_index_wrap'
418 | _p_func(_fmt, ##__VA_ARGS__);
\
| ^~~
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
| ^~
arch/powerpc/kernel/trace/ftrace.c:379:17: note: in expansion of macro 'pr_err'
379 | pr_err("Not expected bl: opcode is %s\n",
ppc_inst_as_str(op));
| ^~
./arch/powerpc/include/asm/inst.h:156:14: note: '__str' declared here
156 | char __str[PPC_INST_STR_LEN]; \
| ^
./include/linux/printk.h:418:33: note: in expansion of macro 'ppc_inst_as_str'
418 | _p_func(_fmt, ##__VA_ARGS__);
\
| ^~~
./include/linux/printk.h:446:26: note: in expansion of macro 'printk_index_wrap'
446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ^
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
489 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
| ^~
arch/powerpc/kernel/trace/ftrace.c:379:17: note: in expansion of macro 'pr_err'
379 | pr_err("Not expected bl: opcode is %s\n",
ppc_inst_as_str(op));
| ^~
arch/powerpc/kernel/trace/ftrace.c: In function '__ftrace_make_call_kernel':
./include/linux/printk.h:446:44: error: using a dangling pointer to '__str'
[-Werror=dangling-pointer=]
446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
|^
./include/linux/printk.h:418:17: note: in definition of macro
'printk_index_wrap'
418 | _p_func(_fmt, ##__VA_ARGS__);
\
| ^~~
./include/linux/printk.h:489:9: note: in expansion of macro 'printk'
489 | printk(KERN_ERR
[PATCH] soc: fsl: qe: Deal with the return value of platform_driver_register
As platform_driver_register() could fail, it should be better
to deal with the return value in order to maintain the code
consisitency.
Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to
platform_device")
Signed-off-by: Jiasheng Jiang
---
drivers/soc/fsl/qe/qe_ic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index bbae3d39c7be..f17de6000ff2 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -481,7 +481,6 @@ static struct platform_driver qe_ic_driver =
static int __init qe_ic_of_init(void)
{
- platform_driver_register(_ic_driver);
- return 0;
+ return platform_driver_register(_ic_driver);
}
subsys_initcall(qe_ic_of_init);
--
2.25.1
Re: [PATCH net-next] eth: de4x5: remove support for Generic DECchip & DIGITAL EtherWORKS PCI/EISA
On Thu, May 26, 2022 at 9:43 AM Geert Uytterhoeven wrote: > On Sat, 21 May 2022, Benjamin Herrenschmidt wrote: > > On Wed, 2022-05-18 at 20:13 -0700, Jakub Kicinski wrote: > >> Looks like almost all changes to this driver had been tree-wide > >> refactoring since git era begun. There is one commit from Al > >> 15 years ago which could potentially be fixing a real bug. > >> > >> The driver is using virt_to_bus() and is a real magnet for pointless > >> cleanups. It seems unlikely to have real users. Let's try to shed > >> this maintenance burden. > >> > >> Signed-off-by: Jakub Kicinski > > > > Removing this driver will kill support for some rather old PowerMac > > models (some PowerBooks I think, paulus would know). No objection on my > > part, though. I doubt people still use these things with new kernels > > but ... who knows ? :-) > > Aren't these PCI, and thus working fine with the PCI-only DE2104X > (dc2104x) or TULIP (dc2114x) drivers? > > IIRC, I've initially used the de4x5 driver on Alpha (UDB/Multia) or PPC > (CHRP), but switched to the TULIP driver later (that was before the > dc2104x/dc2114x driver split, hence a lng time ago). The PCI device IDs say this is correct: there are four IDs in the de4x5 driver, all of which are also listed in one of the two other drivers. Arnd
Re: [PATCH net-next] eth: de4x5: remove support for Generic DECchip & DIGITAL EtherWORKS PCI/EISA
Hi Ben,
On Sat, 21 May 2022, Benjamin Herrenschmidt wrote:
On Wed, 2022-05-18 at 20:13 -0700, Jakub Kicinski wrote:
Looks like almost all changes to this driver had been tree-wide
refactoring since git era begun. There is one commit from Al
15 years ago which could potentially be fixing a real bug.
The driver is using virt_to_bus() and is a real magnet for pointless
cleanups. It seems unlikely to have real users. Let's try to shed
this maintenance burden.
Signed-off-by: Jakub Kicinski
Removing this driver will kill support for some rather old PowerMac
models (some PowerBooks I think, paulus would know). No objection on my
part, though. I doubt people still use these things with new kernels
but ... who knows ? :-)
Aren't these PCI, and thus working fine with the PCI-only DE2104X
(dc2104x) or TULIP (dc2114x) drivers?
IIRC, I've initially used the de4x5 driver on Alpha (UDB/Multia) or PPC
(CHRP), but switched to the TULIP driver later (that was before the
dc2104x/dc2114x driver split, hence a lng time ago).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 1/2] powerpc: Kconfig: Replace tabs with whitespaces
Replace tabs after keywords with whitespaces to be consistent. Signed-off-by: Juerg Haefliger --- arch/powerpc/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 174edabb74fa..b4acaa77837a 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -11,7 +11,7 @@ config 64BIT config LIVEPATCH_64 def_bool PPC64 - depends on LIVEPATCH + depends on LIVEPATCH config MMU bool @@ -446,7 +446,7 @@ choice default MATH_EMULATION_FULL depends on MATH_EMULATION -config MATH_EMULATION_FULL +config MATH_EMULATION_FULL bool "Emulate all the floating point instructions" help Select this option will enable the kernel to support to emulate @@ -1235,7 +1235,7 @@ config PHYSICAL_START default "0x" endif -config ARCH_RANDOM +config ARCH_RANDOM def_bool n config PPC_LIB_RHEAP -- 2.32.0
[PATCH 2/2] powerpc: Kconfig.debug: Remove extra empty line
Remove a stray extra empty line. Signed-off-by: Juerg Haefliger --- arch/powerpc/Kconfig.debug | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug index 192f0ed0097f..2c019e4ac432 100644 --- a/arch/powerpc/Kconfig.debug +++ b/arch/powerpc/Kconfig.debug @@ -305,7 +305,6 @@ config PPC_EARLY_DEBUG_OPAL def_bool y depends on PPC_EARLY_DEBUG_OPAL_RAW || PPC_EARLY_DEBUG_OPAL_HVSI - config PPC_EARLY_DEBUG_HVSI_VTERMNO hex "vterm number to use with early debug HVSI" depends on PPC_EARLY_DEBUG_LPAR_HVSI -- 2.32.0
[PATCH 0/2] powerpc: Kconfig cleanups
Replace some stray tabs with whitespaces and remove an extra empty line. Juerg Haefliger (2): powerpc: Kconfig: Replace tabs with whitespaces powerpc: Kconfig.debug: Remove extra empty line arch/powerpc/Kconfig | 6 +++--- arch/powerpc/Kconfig.debug | 1 - 2 files changed, 3 insertions(+), 4 deletions(-) -- 2.32.0
Re: [Buildroot] [PATCH] linux: Fix powerpc64le defconfig selection
Arnout Vandecappelle writes: > On 16/05/2022 15:17, Michael Ellerman wrote: >> Arnout Vandecappelle writes: >>> On 10/05/2022 04:20, Joel Stanley wrote: The default defconfig target for the 64 bit powerpc kernel is ppc64_defconfig, the big endian configuration. When building for powerpc64le users want the little endian kernel as they can't boot LE userspace on a BE kernel. Fix up the defconfig used in this case. This will avoid the following autobuilder failure: VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o cc1: error: ‘-m32’ not supported in this configuratioin make[4]: *** [arch/powerpc/kernel/vdso32/Makefile:49: arch/powerpc/kernel/vdso32/sigtramp.o] Error 1 http://autobuild.buildroot.net/results/dd76d53bab56470c0b83e296872d7bb90f9e8296/ Note that the failure indicates the toolchain is configured to disable the 32 bit target, causing the kernel to fail when building the 32 bit VDSO. This is only a problem on the BE kernel as the LE kernel disables CONFIG_COMPAT, aka 32 bit userspace support, by default. Signed-off-by: Joel Stanley >>> >>>Applied to master, thanks. However, the defconfig mechanism for *all* >>> powerpc >>> seems pretty broken. Here's what we have in 5.16, before that there was >>> something similar: >>> >>> # If we're on a ppc/ppc64/ppc64le machine use that defconfig, otherwise >>> just use >>> # ppc64_defconfig because we have nothing better to go on. >>> uname := $(shell uname -m) >>> KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64)_defconfig >>> >>>So I guess we should use a specific defconfig for *all* powerpc. >>> >>>The arch-default defconfig is generally not really reliable, for example >>> for >>> arm it always takes v7_multi, but that won't work for v7m targets... >> >> There's a fundamental problem that just the "arch" is not sufficient >> detail when you're building a kernel. > > Yes, which is pretty much unavoidable. > >> Two CPUs that implement the same user-visible "arch" may differ enough >> at the kernel level to require a different defconfig. >> >> Having said that I think we could handle this better in the powerpc >> kernel. Other arches allow specifying a different value for ARCH, which >> then is fed into the defconfig. > > I don't know if it's worth bothering with that. It certainly would not make > our life easier, because it would mean we need to set ARCH correctly. If we > can > do that, we can just as well set the defconfig correctly. OK. >> That way you could at least pass ARCH=ppc/ppc64/ppc64le, and get an >> appropriate defconfig. >> >> I'll work on some kernel changes for that. > > I think the most important thing is that it makes no sense to rely on uname > when ARCH and/or CROSS_COMPILE are set. I'm not sure I entirely agree. Neither ARCH or CROSS_COMPILE give us enough information to know which defconfig to use, so we still have to guess somehow. CROSS_COMPILE can be set even when you're building on ppc, it's the easiest way to specfiy a different toolchain from the default. cheers
[PATCH] powerpc/perf: Give generic PMU a nice name
When booting on a machine that uses the compat pmu driver we see this:
[0.071192] GENERIC_COMPAT performance monitor hardware support registered
Which is a bit shouty. Give it a nicer name.
Signed-off-by: Joel Stanley
---
Other options:
- ISAv3 (because it is relevant for PowerISA 3.0B and beyond, see the
comment in init_generic_compat_pmu)
- Generic Compat (same, but less shouty)
arch/powerpc/perf/generic-compat-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/generic-compat-pmu.c
b/arch/powerpc/perf/generic-compat-pmu.c
index f3db88aee4dd..5be5a5ebaf42 100644
--- a/arch/powerpc/perf/generic-compat-pmu.c
+++ b/arch/powerpc/perf/generic-compat-pmu.c
@@ -292,7 +292,7 @@ static int generic_compute_mmcr(u64 event[], int n_ev,
}
static struct power_pmu generic_compat_pmu = {
- .name = "GENERIC_COMPAT",
+ .name = "Architected",
.n_counter = MAX_PMU_COUNTERS,
.add_fields = ISA207_ADD_FIELDS,
.test_adder = ISA207_TEST_ADDER,
--
2.35.1
