Re: [PATCH] mm/huge_memory: Fix vmf_insert_pfn_{pmd, pud}() crash, handle unaligned addresses
>
> Starting with commit c6f3c5ee40c1 "mm/huge_memory.c: fix modifying of
> page protection by insert_pfn_pmd()" vmf_insert_pfn_pmd() internally
> calls pmdp_set_access_flags(). That helper enforces a pmd aligned
> @address argument via VM_BUG_ON() assertion.
>
> Update the implementation to take a 'struct vm_fault' argument directly
> and apply the address alignment fixup internally to fix crash signatures
> like:
>
> kernel BUG at arch/x86/mm/pgtable.c:515!
> invalid opcode: [#1] SMP NOPTI
> CPU: 51 PID: 43713 Comm: java Tainted: G OE 4.19.35 #1
> [..]
> RIP: 0010:pmdp_set_access_flags+0x48/0x50
> [..]
> Call Trace:
> vmf_insert_pfn_pmd+0x198/0x350
> dax_iomap_fault+0xe82/0x1190
> ext4_dax_huge_fault+0x103/0x1f0
> ? __switch_to_asm+0x40/0x70
> __handle_mm_fault+0x3f6/0x1370
> ? __switch_to_asm+0x34/0x70
> ? __switch_to_asm+0x40/0x70
> handle_mm_fault+0xda/0x200
> __do_page_fault+0x249/0x4f0
> do_page_fault+0x32/0x110
> ? page_fault+0x8/0x30
> page_fault+0x1e/0x30
>
> Cc: vger.kernel.org>
> Fixes: c6f3c5ee40c1 ("mm/huge_memory.c: fix modifying of page protection by
> insert_pfn_pmd()")
> Reported-by: Piotr Balcer
> Tested-by: Yan Ma
> Cc: Aneesh Kumar K.V
> Cc: Chandan Rajendra
> Cc: Jan Kara suse.cz>
> Cc: Andrew Morton
> Cc: Matthew Wilcox infradead.org>
> Cc: Souptick Joarder
> Signed-off-by: Dan Williams
> ---
>
> drivers/dax/device.c|6 ++
> fs/dax.c|6 ++
> include/linux/huge_mm.h |6 ++
> mm/huge_memory.c| 16 ++--
> 4 files changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> index e428468ab661..996d68ff992a 100644
> --- a/drivers/dax/device.c
> +++ b/drivers/dax/device.c
> @@ -184,8 +184,7 @@ static vm_fault_t __dev_dax_pmd_fault(struct dev_dax
> *dev_dax,
>
> *pfn = phys_to_pfn_t(phys, dax_region->pfn_flags);
>
> -return vmf_insert_pfn_pmd(vmf->vma, vmf->address, vmf->pmd, *pfn,
> -vmf->flags & FAULT_FLAG_WRITE);
> +return vmf_insert_pfn_pmd(vmf, *pfn, vmf->flags & FAULT_FLAG_WRITE);
> }
>
> #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> @@ -235,8 +234,7 @@ static vm_fault_t __dev_dax_pud_fault(struct dev_dax
> *dev_dax,
>
> *pfn = phys_to_pfn_t(phys, dax_region->pfn_flags);
>
> -return vmf_insert_pfn_pud(vmf->vma, vmf->address, vmf->pud, *pfn,
> -vmf->flags & FAULT_FLAG_WRITE);
> +return vmf_insert_pfn_pud(vmf, *pfn, vmf->flags & FAULT_FLAG_WRITE);
> }
> #else
> static vm_fault_t __dev_dax_pud_fault(struct dev_dax *dev_dax,
> diff --git a/fs/dax.c b/fs/dax.c
> index e5e54da1715f..83009875308c 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1575,8 +1575,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct vm_fault
> *vmf, pfn_t *pfnp,
> }
>
> trace_dax_pmd_insert_mapping(inode, vmf, PMD_SIZE, pfn,
> entry);
> -result = vmf_insert_pfn_pmd(vma, vmf->address, vmf->pmd, pfn,
> -write);
> +result = vmf_insert_pfn_pmd(vmf, pfn, write);
> break;
> case IOMAP_UNWRITTEN:
> case IOMAP_HOLE:
> @@ -1686,8 +1685,7 @@ dax_insert_pfn_mkwrite(struct vm_fault *vmf, pfn_t pfn,
> unsigned int order)
> ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn);
> #ifdef CONFIG_FS_DAX_PMD
> else if (order == PMD_ORDER)
> -ret = vmf_insert_pfn_pmd(vmf->vma, vmf->address, vmf->pmd,
> -pfn, true);
> +ret = vmf_insert_pfn_pmd(vmf, pfn, FAULT_FLAG_WRITE);
> #endif
> else
> ret = VM_FAULT_FALLBACK;
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 381e872bfde0..7cd5c150c21d 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -47,10 +47,8 @@ extern bool move_huge_pmd(struct vm_area_struct *vma,
> unsigned long old_addr,
> extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
> unsigned long addr, pgprot_t newprot,
> int prot_numa);
> -vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long
> addr,
> -pmd_t *pmd, pfn_t pfn, bool write);
> -vm_fault_t vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long
> addr,
> -pud_t *pud, pfn_t pfn, bool write);
> +vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write);
> +vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write);
> enum transparent_hugepage_flag {
> TRANSPARENT_HUGEPAGE_FLAG,
> TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 165ea46bf149..4310c6e9e5a3 100644
> --- a/mm/huge_memory.c
>
Re: [EXT] [PATCH 4.19 60/66] scsi: qla2xxx: Fix device staying in blocked state
On Thu, May 09, 2019 at 08:28:29PM +, Quoc Tran wrote: > Hi All, > > Please, remove Quoc Tran (qt...@marvell.com) from this email. I think the > correct contact is Quinn Tran (qut...@marvell.com) I can't go back and rewrite git history, sorry. greg k-h
Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle
> +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned npss)
> +{
> + int ret;
> +
> + mutex_lock(>scan_lock);
> + nvme_start_freeze(ctrl);
> + nvme_wait_freeze(ctrl);
> + ret = nvme_set_features(ctrl, NVME_FEAT_POWER_MGMT, npss, NULL, 0,
> + NULL);
> + nvme_unfreeze(ctrl);
> + mutex_unlock(>scan_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(nvme_set_power);
I think we should have this in the PCIe driver, givn that while in
theory power states are generic in practice they are only applicable
to PCIe. To be revisited if history proves me wrong.
Also I don't see any reason why we'd need to do the freeze game on
resume. Even on suspend it looks a little odd to me, as in theory
the PM core should have already put the system into a quiescent state.
But maybe we actually need it there, in which case a comment would
be helpful.
> + if (!pm_suspend_via_firmware())
pm_suspend_via_firmware is a weird name and has absolutely zero
documentation. So I think we really need a big fat comment with the
wisdom from this thread here.
> + return nvme_set_power(>ctrl, ndev->ctrl.npss);
I think we need to skip this code path is NPSS is zero, as that
indicates that the device doesn't actually do power states and fall
back to the full teardown.
Also I can't find anything except for this odd sentences in the spec:
"Hosts that do not dynamically manage power should set the power
state to the lowest numbered state that satisfies the PCI Express
slot power limit control value.
that requires the power states to be ordered in any particular way.
So we probably have to read through the table at probing time and find
the lowest power state there.
Rafael also brought up the issue of not entering D3, and the somewhat
non-intuitive to me solution for it, so I'm not commenting on that
except for asking on a comment on that save_state call.
> + if (!pm_suspend_via_firmware())
> + return nvme_set_power(>ctrl, 0);
Don't we need to save the previous power state here and restore that?
For example if someone set a specific state through nvme-cli?
linux-next: Tree for May 10
Hi all, Please do not add any v5.3 material to your linux-next included trees/branches until after v5.2-rc1 has been released. Changes since 20190509: The netfilter tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 3561 3382 files changed, 113022 insertions(+), 44354 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (abde77eb5c66 Merge branch 'for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup) Merging fixes/master (d15da9d3fb74 kernel/compat.c: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (ccaa75187a5f memstick: mark expected switch fall-throughs) Merging kbuild-current/fixes (a2d635decbfa Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm) Merging arc-current/for-curr (8b21baee8e48 ARC: fix build warnings) Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache) Merging arm64-fixes/for-next/fixes (4e69ecf4da1e arm64/module: ftrace: deal with place relative nature of PLTs) Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: Mark m68k having modern-timekeeping) Merging powerpc-fixes/fixes (12f363511d47 powerpc/32s: Fix BATs setting with CONFIG_STRICT_KERNEL_RWX) Merging sparc/master (f4d9a23d3dad sparc64: simplify reduce_memory() function) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (36096f2f4fa0 packet: Fix error path in packet_init) Merging bpf/master (494bc1d281b5 net/tcp: use deferred jump label for TCP acked data hook) Merging ipsec/master (9b3040a6aafd ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled) Merging netfilter/master (c6c9c0596c21 netfilter: nf_tables: remove NFT_CT_TIMEOUT) CONFLICT (content): Merge conflict in include/uapi/linux/netfilter/nf_tables.h Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (7a0f8ad5ff63 Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git) Merging mac80211/master (5f05836831f6 net/sched: avoid double free on matchall reoffload) Merging rdma-fixes/for-rc (2557fabd6e29 RDMA/hns: Bugfix for mapping user db) Merging sound-current/for-linus (ed97c988bdc6 Merge tag 'asoc-v5.2-5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (7663ec3c9249 Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (7fdc9fc87492 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (c7b5128f72ef Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (c84e8dd1bfcb Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (9c9c5fc89b09 PCI/LINK: Add Kconfig option (default off)) Merging driver-core.current/driver-core-linus (e7a1414f9dc3 Merge tag 'media/v5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging tty.current/tty-linus (e7a1414f9dc3 Merge tag 'media/v5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging u
Re: [PATCH] arm64: arch_k3: Fix kconfig dependency warning
On 10/05/19 9:22 AM, YueHaibing wrote:
> Fix Kbuild warning when SOC_TI is not set
>
> WARNING: unmet direct dependencies detected for TI_SCI_INTA_IRQCHIP
> Depends on [n]: TI_SCI_PROTOCOL [=y] && SOC_TI [=n]
> Selected by [y]:
> - ARCH_K3 [=y]
>
> Fixes: 009669e74813 ("arm64: arch_k3: Enable interrupt controller drivers")
> Signed-off-by: YueHaibing
Thanks for catching it.
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 42eca65..9d1292f 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -88,6 +88,7 @@ config ARCH_K3
> bool "Texas Instruments Inc. K3 multicore SoC architecture"
> select PM_GENERIC_DOMAINS if PM
> select MAILBOX
> + select SOC_TI
> select TI_MESSAGE_MANAGER
> select TI_SCI_PROTOCOL
> select TI_SCI_INTR_IRQCHIP
>
Re: WARNING: locking bug in copy_process
On May 10, 2019 3:07:05 AM GMT+02:00, syzbot
wrote:
>Hello,
>
>syzbot found the following crash on:
>
>HEAD commit:a2d635de Merge tag 'drm-next-2019-05-09' of
>git://anongit...
>git tree: upstream
>console output:
>https://syzkaller.appspot.com/x/log.txt?x=12b36dd0a0
>kernel config:
>https://syzkaller.appspot.com/x/.config?x=2ef407aed78c3758
>dashboard link:
>https://syzkaller.appspot.com/bug?extid=3286e58549edc479faae
>compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>userspace arch: i386
>syz repro:
>https://syzkaller.appspot.com/x/repro.syz?x=12d85ec8a0
>C reproducer:
>https://syzkaller.appspot.com/x/repro.c?x=11df8778a0
>
>The bug was bisected to:
>
>commit b3e5838252665ee4cfa76b82bdf1198dca81e5be
>Author: Christian Brauner
>Date: Wed Mar 27 12:04:15 2019 +
>
> clone: add CLONE_PIDFD
>
>bisection log:
>https://syzkaller.appspot.com/x/bisect.txt?x=14fe77b4a0
>final crash:
>https://syzkaller.appspot.com/x/report.txt?x=16fe77b4a0
>console output:
>https://syzkaller.appspot.com/x/log.txt?x=12fe77b4a0
>
>IMPORTANT: if you fix the bug, please add the following tag to the
>commit:
>Reported-by: syzbot+3286e58549edc479f...@syzkaller.appspotmail.com
>Fixes: b3e583825266 ("clone: add CLONE_PIDFD")
>
> entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
>RIP: 0023:0xf7fec849
>Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90
>90
>90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3
>90
>90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
>RSP: 002b:ffed5a8c EFLAGS: 0246 ORIG_RAX: 0078
>RAX: ffda RBX: 3ffc RCX:
>RDX: 25c0 RSI: RDI:
>RBP: 0012 R08: R09:
>R10: R11: R12:
>R13: R14: R15:
>[ cut here ]
>DEBUG_LOCKS_WARN_ON(depth <= 0)
>WARNING: CPU: 1 PID: 7744 at kernel/locking/lockdep.c:4052
>__lock_release
>kernel/locking/lockdep.c:4052 [inline]
>WARNING: CPU: 1 PID: 7744 at kernel/locking/lockdep.c:4052
>lock_release+0x667/0xa00 kernel/locking/lockdep.c:4321
>Kernel panic - not syncing: panic_on_warn set ...
>CPU: 1 PID: 7744 Comm: syz-executor007 Not tainted 5.1.0+ #4
>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>
>Google 01/01/2011
>Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> panic+0x2cb/0x65c kernel/panic.c:214
> __warn.cold+0x20/0x45 kernel/panic.c:566
> report_bug+0x263/0x2b0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:179 [inline]
> fixup_bug arch/x86/kernel/traps.c:174 [inline]
> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
> do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:972
>RIP: 0010:__lock_release kernel/locking/lockdep.c:4052 [inline]
>RIP: 0010:lock_release+0x667/0xa00 kernel/locking/lockdep.c:4321
>Code: 0f 85 a0 03 00 00 8b 35 77 66 08 08 85 f6 75 23 48 c7 c6 a0 55 6b
>87
>48 c7 c7 40 25 6b 87 4c 89 85 70 ff ff ff e8 b7 a9 eb ff <0f> 0b 4c 8b
>85
>70 ff ff ff 4c 89 ea 4c 89 e6 4c 89 c7 e8 52 63 ff
>RSP: 0018:888094117b48 EFLAGS: 00010086
>RAX: RBX: 111012822f6f RCX:
>RDX: RSI: 815af236 RDI: ed1012822f5b
>RBP: 888094117c00 R08: 888092bfc400 R09: fbfff113301d
>R10: fbfff113301c R11: 889980e3 R12: 8a451df8
>R13: 8142e71f R14: 8a44cc80 R15: 888094117bd8
> percpu_up_read.constprop.0+0xcb/0x110 include/linux/percpu-rwsem.h:92
> cgroup_threadgroup_change_end include/linux/cgroup-defs.h:712 [inline]
> copy_process.part.0+0x47ff/0x6710 kernel/fork.c:
> copy_process kernel/fork.c:1772 [inline]
> _do_fork+0x25d/0xfd0 kernel/fork.c:2338
> __do_compat_sys_x86_clone arch/x86/ia32/sys_ia32.c:240 [inline]
> __se_compat_sys_x86_clone arch/x86/ia32/sys_ia32.c:236 [inline]
> __ia32_compat_sys_x86_clone+0xbc/0x140 arch/x86/ia32/sys_ia32.c:236
> do_syscall_32_irqs_on arch/x86/entry/common.c:334 [inline]
> do_fast_syscall_32+0x281/0xd54 arch/x86/entry/common.c:405
> entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
>RIP: 0023:0xf7fec849
>Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90
>90
>90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3
>90
>90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
>RSP: 002b:ffed5a8c EFLAGS: 0246 ORIG_RAX: 0078
>RAX: ffda RBX: 3ffc RCX:
>RDX: 25c0 RSI: RDI:
>RBP: 0012 R08: R09:
>R10: R11: R12:
>R13:
RE: [PATCH] ARM: imx_v6_v7_defconfig: Enable CONFIG_THERMAL_STATISTICS
Hi, Shawn > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: Friday, May 10, 2019 11:29 AM > To: Anson Huang > Cc: li...@armlinux.org.uk; s.ha...@pengutronix.de; > ker...@pengutronix.de; feste...@gmail.com; ota...@ossystems.com.br; > Leonard Crestez ; Robin Gong > ; u.kleine-koe...@pengutronix.de; > jan.tu...@emtrion.com; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; dl-linux-imx > Subject: Re: [PATCH] ARM: imx_v6_v7_defconfig: Enable > CONFIG_THERMAL_STATISTICS > > On Wed, Apr 24, 2019 at 03:27:13AM +, Anson Huang wrote: > > Enable CONFIG_THERMAL_STATISTICS to extend the sysfs interface for > > thermal cooling devices and expose some useful statistics. > > > > Signed-off-by: Anson Huang > > I don't apply patch using base64 encoding. It is our server issue and we have reported it to local IT, will resend patch once issue is solved. Thanks, Anson. > > Shawn
Re: [PATCH 2/4] x86/kprobes: Fix frame pointer annotations
On Thu, 9 May 2019 19:14:16 +0200
Peter Zijlstra wrote:
> On Thu, May 09, 2019 at 11:01:06PM +0900, Masami Hiramatsu wrote:
> > On Thu, 9 May 2019 10:14:31 +0200
> > Peter Zijlstra wrote:
>
> > > But what I'd love to do is something like the belwo patch, and make all
> > > the trampolines (very much including ftrace) use that. Such that we then
> > > only have 1 copy of this magic (well, 2 because x86_64 also needs an
> > > implementation of this of course).
> >
> > OK, but I will make kretprobe integrated with func-graph tracer,
> > since it is inefficient that we have 2 different hidden return stack...
> >
> > Anyway,
> >
> > > Changing ftrace over to this would be a little more work but it can
> > > easily chain things a little to get its original context back:
> > >
> > > ENTRY(ftrace_regs_caller)
> > > GLOBAL(ftrace_regs_func)
> > > push ftrace_stub
> > > push ftrace_regs_handler
> > > jmp call_to_exception_trampoline
> > > END(ftrace_regs_caller)
> > >
> > > typedef void (*ftrace_func_t)(unsigned long, unsigned long, struct
> > > ftrace_op *, struct pt_regs *);
> > >
> > > struct ftrace_regs_stack {
> > > ftrace_func_t func;
> > > unsigned long parent_ip;
> > > };
> > >
> > > void ftrace_regs_handler(struct pr_regs *regs)
> > > {
> > > struct ftrace_regs_stack *st = (void *)regs->sp;
> > > ftrace_func_t func = st->func;
> > >
> > > regs->sp += sizeof(long); /* pop func */
> >
> > Sorry, why pop here?
>
> Otherwise it stays on the return stack and bad things happen. Note how
> the below trampoline thing uses regs->sp.
>
> > > func(regs->ip, st->parent_ip, function_trace_op, regs);
> > > }
> > >
> > > Hmm? I didn't look into the function_graph thing, but I imagine it can
> > > be added without too much pain.
> >
> > Yes, that should be good for function_graph trampoline too.
> > We use very similar technic.
>
> Ideally also the optimized kprobe trampoline, but I've not managed to
> fully comprehend that one.
As you pointed in other reply, save/restore can be a macro, but
each trampoline code is slightly different. Optprobe template has
below parts
(jumped from probed address)
[store regs]
[setup function arguments (pt_regs and probed address)]
[handler call]
[restore regs]
[execute copied instruction]
[jump back to probed address]
Note that there is a limitation that if it is optiomized probe, user
handler can not change regs->ip. (we can not use "ret" after executed
a copied instruction, which must run on same stack)
>
> > >
> > > ---
> > > --- a/arch/x86/entry/entry_32.S
> > > +++ b/arch/x86/entry/entry_32.S
> > > @@ -1576,3 +1576,100 @@ ENTRY(rewind_stack_do_exit)
> > > calldo_exit
> > > 1: jmp 1b
> > > END(rewind_stack_do_exit)
> > > +
> > > +/*
> > > + * Transforms a CALL frame into an exception frame; IOW it pretends the
> > > CALL we
> > > + * just did was in fact scribbled with an INT3.
> > > + *
> > > + * Use this trampoline like:
> > > + *
> > > + * PUSH $func
> > > + * JMP call_to_exception_trampoline
> > > + *
> > > + * $func will see regs->ip point at the CALL instruction and must
> > > therefore
> > > + * modify regs->ip in order to make progress (just like a normal INT3
> > > scribbled
> > > + * CALL).
> > > + *
> > > + * NOTE: we do not restore any of the segment registers.
> > > + */
> > > +ENTRY(call_to_exception_trampoline)
> > > + /*
> > > + * On entry the stack looks like:
> > > + *
> > > + * 2*4(%esp)
> > > + * 1*4(%esp) RET-IP
> > > + * 0*4(%esp) func
> > > + *
> > > + * transform this into:
> > > + *
> > > + * 19*4(%esp)
> > > + * 18*4(%esp) gap / RET-IP
> > > + * 17*4(%esp) gap / func
> > > + * 16*4(%esp) ss
> > > + * 15*415*4(%esp) sp /
> >
> > isn't this "&" ?
>
> Yes.
>
> > > + * 14*4(%esp) flags
> > > + * 13*4(%esp) cs
> > > + * 12*4(%esp) ip / RET-IP
> > > + * 11*4(%esp) orig_eax
> > > + * 10*4(%esp) gs
> > > + * 9*4(%esp) fs
> > > + * 8*4(%esp) es
> > > + * 7*4(%esp) ds
> > > + * 6*4(%esp) eax
> > > + * 5*4(%esp) ebp
> > > + * 4*4(%esp) edi
> > > + * 3*4(%esp) esi
> > > + * 2*4(%esp) edx
> > > + * 1*4(%esp) ecx
> > > + * 0*4(%esp) ebx
> > > + */
> > > + pushl %ss
> > > + pushl %esp# points at ss
> > > + addl$3*4, (%esp)# point it at
> > > + pushfl
> > > + pushl %cs
> > > + pushl 5*4(%esp) # RET-IP
> > > + subl5, (%esp) # point at CALL instruction
> > > + pushl $-1
> > > + pushl %gs
> > > + pushl %fs
> > > + pushl %es
> > > + pushl %ds
> > > + pushl %eax
> > > + pushl %ebp
> > > + pushl %edi
> > > + pushl %esi
> > > + pushl %edx
> > > + pushl %ecx
> > > + pushl %ebx
> > > +
> > > + ENCODE_FRAME_POINTER
> > > +
> > > + movl%esp, %eax # 1st argument: pt_regs
> > > +
> > > + movl17*4(%esp), %ebx# func
> > > + CALL_NOSPEC %ebx
> > > +
> > > + movlPT_OLDESP(%esp), %eax
> >
> > Is PT_OLDESP(%esp) "" or "&"?
>
> The latter.
>
> > > +
> > > + movl
[PATCH v2 2/8] remoteproc: qcom: qdsp6-adsp: Add support for QCS404 CDSP
Move the clock list to adsp_pil_data, make the pdc_reset optional and
make the driver directly enable the xo, sleep and core clocks.
The three clocks are previously toggled through the clock controller,
but that means the same hardware block needs to be mapped in both
drivers. Making the remoteproc driver enable the clocks is a nop when
using the clock controller, but allow us to remove the clocks from the
clock controller.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/qcom_q6v5_adsp.c | 73 ++---
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index 1f3ef9ee493c..e953886b2eb7 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -46,11 +46,9 @@
#define LPASS_PWR_ON_REG 0x10
#define LPASS_HALTREQ_REG 0x0
-/* list of clocks required by ADSP PIL */
-static const char * const adsp_clk_id[] = {
- "sway_cbcr", "lpass_ahbs_aon_cbcr", "lpass_ahbm_aon_cbcr",
- "qdsp6ss_xo", "qdsp6ss_sleep", "qdsp6ss_core",
-};
+#define QDSP6SS_XO_CBCR0x38
+#define QDSP6SS_CORE_CBCR 0x20
+#define QDSP6SS_SLEEP_CBCR 0x3c
struct adsp_pil_data {
int crash_reason_smem;
@@ -59,6 +57,9 @@ struct adsp_pil_data {
const char *ssr_name;
const char *sysmon_name;
int ssctl_id;
+
+ const char **clk_ids;
+ int num_clks;
};
struct qcom_adsp {
@@ -75,7 +76,7 @@ struct qcom_adsp {
void __iomem *qdsp6ss_base;
struct reset_control *pdc_sync_reset;
- struct reset_control *cc_lpass_restart;
+ struct reset_control *restart;
struct regmap *halt_map;
unsigned int halt_lpass;
@@ -143,7 +144,7 @@ static int qcom_adsp_shutdown(struct qcom_adsp *adsp)
/* Assert the LPASS PDC Reset */
reset_control_assert(adsp->pdc_sync_reset);
/* Place the LPASS processor into reset */
- reset_control_assert(adsp->cc_lpass_restart);
+ reset_control_assert(adsp->restart);
/* wait after asserting subsystem restart from AOSS */
usleep_range(200, 300);
@@ -153,7 +154,7 @@ static int qcom_adsp_shutdown(struct qcom_adsp *adsp)
/* De-assert the LPASS PDC Reset */
reset_control_deassert(adsp->pdc_sync_reset);
/* Remove the LPASS reset */
- reset_control_deassert(adsp->cc_lpass_restart);
+ reset_control_deassert(adsp->restart);
/* wait after de-asserting subsystem restart from AOSS */
usleep_range(200, 300);
@@ -192,6 +193,15 @@ static int adsp_start(struct rproc *rproc)
goto disable_power_domain;
}
+ /* Enable the XO clock */
+ writel(1, adsp->qdsp6ss_base + QDSP6SS_XO_CBCR);
+
+ /* Enable the QDSP6SS sleep clock */
+ writel(1, adsp->qdsp6ss_base + QDSP6SS_SLEEP_CBCR);
+
+ /* Enable the QDSP6 core clock */
+ writel(1, adsp->qdsp6ss_base + QDSP6SS_CORE_CBCR);
+
/* Program boot address */
writel(adsp->mem_phys >> 4, adsp->qdsp6ss_base + RST_EVB_REG);
@@ -280,8 +290,9 @@ static const struct rproc_ops adsp_ops = {
.load = adsp_load,
};
-static int adsp_init_clock(struct qcom_adsp *adsp)
+static int adsp_init_clock(struct qcom_adsp *adsp, const char **clk_ids)
{
+ int num_clks = 0;
int i, ret;
adsp->xo = devm_clk_get(adsp->dev, "xo");
@@ -292,32 +303,39 @@ static int adsp_init_clock(struct qcom_adsp *adsp)
return ret;
}
- adsp->num_clks = ARRAY_SIZE(adsp_clk_id);
+ for (i = 0; clk_ids[i]; i++)
+ num_clks++;
+
+ adsp->num_clks = num_clks;
adsp->clks = devm_kcalloc(adsp->dev, adsp->num_clks,
sizeof(*adsp->clks), GFP_KERNEL);
if (!adsp->clks)
return -ENOMEM;
for (i = 0; i < adsp->num_clks; i++)
- adsp->clks[i].id = adsp_clk_id[i];
+ adsp->clks[i].id = clk_ids[i];
return devm_clk_bulk_get(adsp->dev, adsp->num_clks, adsp->clks);
}
static int adsp_init_reset(struct qcom_adsp *adsp)
{
- adsp->pdc_sync_reset = devm_reset_control_get_exclusive(adsp->dev,
+ adsp->pdc_sync_reset =
devm_reset_control_get_optional_exclusive(adsp->dev,
"pdc_sync");
if (IS_ERR(adsp->pdc_sync_reset)) {
dev_err(adsp->dev, "failed to acquire pdc_sync reset\n");
return PTR_ERR(adsp->pdc_sync_reset);
}
- adsp->cc_lpass_restart = devm_reset_control_get_exclusive(adsp->dev,
- "cc_lpass");
- if (IS_ERR(adsp->cc_lpass_restart)) {
- dev_err(adsp->dev, "failed to acquire cc_lpass restart\n");
- return PTR_ERR(adsp->cc_lpass_restart);
+ adsp->restart = devm_reset_control_get_optional_exclusive(adsp->dev,
"restart");
+
+ /* Fall back to the old
[PATCH v2 1/8] dt-bindings: remoteproc: Rename and amend Hexagon v56 binding
The SDM845 Audio DSP peripheral image loader binding describes the
properties needed to load and boot firmware on a Hexagon v56. Rename the
file and add the Compute DSP (CDSP) found in QCS404 to the binding.
Signed-off-by: Bjorn Andersson
---
...qcom,adsp-pil.txt => qcom,hexagon-v56.txt} | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
rename Documentation/devicetree/bindings/remoteproc/{qcom,adsp-pil.txt =>
qcom,hexagon-v56.txt} (74%)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt
similarity index 74%
rename from Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
rename to Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt
index 66af2c30944f..1337a3d93d35 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt
@@ -1,12 +1,13 @@
-Qualcomm Technology Inc. ADSP Peripheral Image Loader
+Qualcomm Technology Inc. Hexagon v56 Peripheral Image Loader
This document defines the binding for a component that loads and boots firmware
-on the Qualcomm Technology Inc. ADSP Hexagon core.
+on the Qualcomm Technology Inc. Hexagon v56 core.
- compatible:
Usage: required
Value type:
Definition: must be one of:
+ "qcom,qcs404-cdsp-pil",
"qcom,sdm845-adsp-pil"
- reg:
@@ -28,10 +29,11 @@ on the Qualcomm Technology Inc. ADSP Hexagon core.
- clocks:
Usage: required
Value type:
- Definition: List of 8 phandle and clock specifier pairs for the adsp.
+ Definition: List of phandles and clock specifier pairs for the Hexagon,
+per clock-names below.
- clock-names:
- Usage: required
+ Usage: required for SDM845 ADSP
Value type:
Definition: List of clock input name strings sorted in the same
order as the clocks property. Definition must have
@@ -39,6 +41,14 @@ on the Qualcomm Technology Inc. ADSP Hexagon core.
"lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep"
and "qdsp6ss_core".
+- clock-names:
+ Usage: required for QCS404 CDSP
+ Value type:
+ Definition: List of clock input name strings sorted in the same
+ order as the clocks property. Definition must have
+ "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave",
+ "q6ss_master", "q6_axim".
+
- power-domains:
Usage: required
Value type:
@@ -47,28 +57,33 @@ on the Qualcomm Technology Inc. ADSP Hexagon core.
- resets:
Usage: required
Value type:
- Definition: reference to the list of 2 reset-controller for the adsp.
+ Definition: reference to the list of resets for the Hexagon.
- reset-names:
-Usage: required
+Usage: required for SDM845 ADSP
Value type:
Definition: must be "pdc_sync" and "cc_lpass"
+- reset-names:
+Usage: required for QCS404 CDSP
+Value type:
+Definition: must be "restart"
+
- qcom,halt-regs:
Usage: required
Value type:
Definition: a phandle reference to a syscon representing TCSR followed
- by the offset within syscon for lpass halt register.
+ by the offset within syscon for Hexagon halt register.
- memory-region:
Usage: required
Value type:
- Definition: reference to the reserved-memory for the ADSP
+ Definition: reference to the reserved-memory for the firmware
- qcom,smem-states:
Usage: required
Value type:
- Definition: reference to the smem state for requesting the ADSP to
+ Definition: reference to the smem state for requesting the Hexagon to
shut down
- qcom,smem-state-names:
@@ -79,7 +94,7 @@ on the Qualcomm Technology Inc. ADSP Hexagon core.
= SUBNODES
The adsp node may have an subnode named "glink-edge" that describes the
-communication edge, channels and devices related to the ADSP.
+communication edge, channels and devices related to the Hexagon.
See ../soc/qcom/qcom,glink.txt for details on how to describe these.
= EXAMPLE
--
2.18.0
[PATCH v2 3/8] arm64: dts: qcom: qcs404-evb: Mark CDSP clocks protected
With the Trustzone based CDSP remoteproc driver these clocks are
controlled elsewhere and as they are not enabled by anything in Linux
the clock framework will turn them off during lateinit.
This results in issues either to later start the CDSP, using the
Trustzone interface, or if the CDSP is already running it will crash.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index 2c3127167e3c..dc1d7d5d21a4 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -56,6 +56,13 @@
qcom,controlled-remotely;
};
+ {
+ protected-clocks = ,
+ ,
+ ,
+ ;
+};
+
_spmi_regulators {
vdd_s3-supply = <_s3>;
--
2.18.0
[PATCH v2 7/8] arm64: dts: qcom: qcs404: Define APPS IOMMU
The APPS IOMMU provides contexts for FastRPC, MDP and WLAN, among other
things. Define these. We use the qcom_iommu binding because the
firmware restrictions in incompatible with the arm-smmu.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 85
1 file changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index b213f6acad76..fcde4f0334c2 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -378,6 +378,91 @@
reg = <0x01937000 0x25000>;
};
+ apps_iommu: iommu@1e2 {
+ compatible = "qcom,qcs404-iommu", "qcom,msm-iommu-v1";
+ clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_APSS_TCU_CLK>;
+ clock-names = "iface", "bus";
+ qcom,iommu-secure-id = <17>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+
+ /* Define ranges such that the first bank is at 0x1000
*/
+ ranges = <0 0x01e2 0x4>;
+
+ /* Bank 5: CDSP compute bank 1 */
+ iommu-ctx@5000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x5000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 6: CDSP compute bank 2 */
+ iommu-ctx@6000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x6000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 7: CDSP compute bank 3 */
+ iommu-ctx@7000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x7000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 8: CDSP compute bank 4 */
+ iommu-ctx@8000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x8000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 9: CDSP compute bank 5 */
+ iommu-ctx@9000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x9000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 10: MDP */
+ iommu-ctx@a000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0xa000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 21: WLAN 0 */
+ iommu-ctx@15000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x15000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 23: ADSP compute bank 2 */
+ iommu-ctx@17000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x17000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 24: ADSP compute bank 3 */
+ iommu-ctx@18000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x18000 0x1000>;
+ interrupts = ;
+ };
+
+ /* Bank 25: ADSP compute bank 4 */
+ iommu-ctx@19000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x19000 0x1000>;
+ interrupts = ;
+ };
+ };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x001000>,
--
2.18.0
[PATCH v2 6/8] arm64: dts: qcom: qcs404: Move lpass and q6 into soc
Although we don't describe lpass and wcss with all the details needed to
control them in a Trustzone-less environment, move them under soc in
order to tidy up the structure and prepare for describing them fully.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 126 ++-
1 file changed, 64 insertions(+), 62 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 896f95817f23..b213f6acad76 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -82,68 +82,6 @@
method = "smc";
};
- remoteproc_adsp: remoteproc-adsp {
- compatible = "qcom,qcs404-adsp-pas";
-
- interrupts-extended = < GIC_SPI 293 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "wdog", "fatal", "ready",
- "handover", "stop-ack";
-
- clocks = <_board>;
- clock-names = "xo";
-
- memory-region = <_fw_mem>;
-
- qcom,smem-states = <_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- status = "disabled";
-
- glink-edge {
- interrupts = ;
-
- qcom,remote-pid = <2>;
- mboxes = <_glb 8>;
-
- label = "adsp";
- };
- };
-
- remoteproc_wcss: remoteproc-wcss {
- compatible = "qcom,qcs404-wcss-pas";
-
- interrupts-extended = < GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "wdog", "fatal", "ready",
- "handover", "stop-ack";
-
- clocks = <_board>;
- clock-names = "xo";
-
- memory-region = <_fw_mem>;
-
- qcom,smem-states = <_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- status = "disabled";
-
- glink-edge {
- interrupts = ;
-
- qcom,remote-pid = <1>;
- mboxes = <_glb 16>;
-
- label = "wcss";
- };
- };
-
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -458,6 +396,38 @@
#interrupt-cells = <4>;
};
+ remoteproc_wcss: remoteproc@740 {
+ compatible = "qcom,qcs404-wcss-pas";
+ reg = <0x0740 0x4040>;
+
+ interrupts-extended = < GIC_SPI 153
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = <_board>;
+ clock-names = "xo";
+
+ memory-region = <_fw_mem>;
+
+ qcom,smem-states = <_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts = ;
+
+ qcom,remote-pid = <1>;
+ mboxes = <_glb 16>;
+
+ label = "wcss";
+ };
+ };
+
sdcc1: sdcc@7804000 {
compatible = "qcom,sdhci-msm-v5";
reg = <0x07804000 0x1000>, <0x7805000 0x1000>;
@@ -843,6 +813,38 @@
status = "disabled";
};
};
+
+ remoteproc_adsp: remoteproc@c70 {
+ compatible = "qcom,qcs404-adsp-pas";
+ reg = <0x0c70 0x4040>;
+
+ interrupts-extended = < GIC_SPI 293
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
+
[PATCH v2 4/8] arm64: dts: qcom: qcs404: Add TCSR node
The bus halt registers in TCSR are referenced as a syscon device, add
these so that we can reference them from the remoteproc nodes.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index f422d6e9cb3a..3eb6089c8024 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -415,6 +415,11 @@
reg = <0x01905000 0x2>;
};
+ tcsr: syscon@1937000 {
+ compatible = "syscon";
+ reg = <0x01937000 0x25000>;
+ };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x001000>,
--
2.18.0
[PATCH v2 8/8] arm64: dts: qcom: qcs404: Add fastrpc nodes
From: Thierry Escande
The ADSP fastrpc provides 3 context banks and are assigned to IOMMU
context banks 23, 24 and 25; using SIDs 0x804, 0x805 and 0x806. The
CDSP fastrpc provides 5 context banks and are assigned to IOMMU context
banks 5, 6, 7, 8 and 9; using SIDs 0x1001 through 0x1005. Add these to
their respective remoteproc.
The lower 4 bits of the SID is used to identify the context bank when
communicating with the fastrpc firmware, so this gives the reg values.
Signed-off-by: Thierry Escande
[bjorn: Added SMMU linkage and extend commit message]
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 66
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index fcde4f0334c2..858a53160564 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -243,6 +243,45 @@
mboxes = <_glb 12>;
label = "cdsp";
+
+ fastrpc_cdsp: fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,glink-channels =
"fastrpcglink-apps-dsp";
+ label = "cdsp";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cb@1 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <1>;
+ iommus = <_iommu 5>;
+ };
+
+ cb@2 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <2>;
+ iommus = <_iommu 6>;
+ };
+
+ cb@3 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <3>;
+ iommus = <_iommu 7>;
+ };
+
+ cb@4 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <4>;
+ iommus = <_iommu 8>;
+ };
+
+ cb@5 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <_iommu 9>;
+ };
+ };
};
};
@@ -928,6 +967,33 @@
mboxes = <_glb 8>;
label = "adsp";
+
+ fastrpc_adsp: fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,glink-channels =
"fastrpcglink-apps-dsp";
+ label = "adsp";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cb@4 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <4>;
+ iommus = <_iommu 23>;
+ };
+
+ cb@5 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <_iommu 24>;
+ };
+
+ cb@6 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <6>;
+ iommus = <_iommu 25>;
+ };
+ };
};
};
};
--
2.18.0
[PATCH v2 5/8] arm64: dts: qcom: qcs404: Fully describe the CDSP
Add all the properties needed to describe the CDSP for both the
Trustzone and non-Trustzone based remoteproc case, allowing any child
devices to be described once by just overriding the compatible to match
the firmware available on the board.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 82 +---
1 file changed, 51 insertions(+), 31 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 3eb6089c8024..896f95817f23 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -113,37 +113,6 @@
};
};
- remoteproc_cdsp: remoteproc-cdsp {
- compatible = "qcom,qcs404-cdsp-pas";
-
- interrupts-extended = < GIC_SPI 229 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
- <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "wdog", "fatal", "ready",
- "handover", "stop-ack";
-
- clocks = <_board>;
- clock-names = "xo";
-
- memory-region = <_fw_mem>;
-
- qcom,smem-states = <_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- status = "disabled";
-
- glink-edge {
- interrupts = ;
-
- qcom,remote-pid = <5>;
- mboxes = <_glb 12>;
-
- label = "cdsp";
- };
- };
-
remoteproc_wcss: remoteproc-wcss {
compatible = "qcom,qcs404-wcss-pas";
@@ -288,6 +257,57 @@
clock-names = "core";
};
+ remoteproc_cdsp: remoteproc@b0 {
+ compatible = "qcom,qcs404-cdsp-pas";
+ reg = <0x00b0 0x4040>;
+
+ interrupts-extended = < GIC_SPI 229
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = <_board>,
+< GCC_CDSP_CFG_AHB_CLK>,
+< GCC_CDSP_TBU_CLK>,
+< GCC_BIMC_CDSP_CLK>,
+< TURING_WRAPPER_AON_CLK>,
+< TURING_Q6SS_AHBS_AON_CLK>,
+< TURING_Q6SS_AHBM_AON_CLK>,
+< TURING_Q6SS_Q6_AXIM_CLK>;
+ clock-names = "xo",
+ "sway",
+ "tbu",
+ "bimc",
+ "ahb_aon",
+ "q6ss_slave",
+ "q6ss_master",
+ "q6_axim";
+
+ resets = < GCC_CDSP_RESTART>;
+ reset-names = "restart";
+
+ qcom,halt-regs = < 0x19004>;
+
+ memory-region = <_fw_mem>;
+
+ qcom,smem-states = <_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts = ;
+
+ qcom,remote-pid = <5>;
+ mboxes = <_glb 12>;
+
+ label = "cdsp";
+ };
+ };
+
tlmm: pinctrl@100 {
compatible = "qcom,qcs404-pinctrl";
reg = <0x0100 0x20>,
--
2.18.0
[PATCH v2 0/8] Qualcomm QCS404 CDSP improvements and fastrpc
This series introduces the non-Trustzone based CDSP support, restructures the
remoteproc nodes in the dts, introduces the IOMMU and adds the fastrpc nodes.
The matrix_multi app is used for verification, the test completes 100% of the
time, but exits only succesfully 70% of the time.
Bjorn Andersson (7):
dt-bindings: remoteproc: Rename and amend Hexagon v56 binding
remoteproc: qcom: qdsp6-adsp: Add support for QCS404 CDSP
arm64: dts: qcom: qcs404-evb: Mark CDSP clocks protected
arm64: dts: qcom: qcs404: Add TCSR node
arm64: dts: qcom: qcs404: Fully describe the CDSP
arm64: dts: qcom: qcs404: Move lpass and q6 into soc
arm64: dts: qcom: qcs404: Define APPS IOMMU
Thierry Escande (1):
arm64: dts: qcom: qcs404: Add fastrpc nodes
...qcom,adsp-pil.txt => qcom,hexagon-v56.txt} | 35 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 7 +
arch/arm64/boot/dts/qcom/qcs404.dtsi | 364 +-
drivers/remoteproc/qcom_q6v5_adsp.c | 73 +++-
4 files changed, 358 insertions(+), 121 deletions(-)
rename Documentation/devicetree/bindings/remoteproc/{qcom,adsp-pil.txt =>
qcom,hexagon-v56.txt} (74%)
--
2.18.0
Re: [PATCH] mm: vmscan: correct nr_reclaimed for THP
> On May 9, 2019, at 9:03 PM, Huang, Ying wrote: > > Yang Shi writes: > >> On 5/9/19 7:12 PM, Huang, Ying wrote: >>> >>> How about to change this to >>> >>> >>> nr_reclaimed += hpage_nr_pages(page); >> >> Either is fine to me. Is this faster than "1 << compound_order(page)"? > > I think the readability is a little better. And this will become > >nr_reclaimed += 1 > > if CONFIG_TRANSPARENT_HUAGEPAGE is disabled. I find this more legible and self documenting, and it avoids the bit shift operation completely on the majority of systems where THP is not configured.
Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak
hi Rob: > As no one else seems to have any comments, I've applied it. Sorry for bothering you. Since I haven't see this patch on below up stream repository, "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git" if there is anything wrong about the patch, please let me know. Appreciate ur kind help,
[PATCH] arm64: arch_k3: Fix kconfig dependency warning
Fix Kbuild warning when SOC_TI is not set
WARNING: unmet direct dependencies detected for TI_SCI_INTA_IRQCHIP
Depends on [n]: TI_SCI_PROTOCOL [=y] && SOC_TI [=n]
Selected by [y]:
- ARCH_K3 [=y]
Fixes: 009669e74813 ("arm64: arch_k3: Enable interrupt controller drivers")
Signed-off-by: YueHaibing
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 42eca65..9d1292f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -88,6 +88,7 @@ config ARCH_K3
bool "Texas Instruments Inc. K3 multicore SoC architecture"
select PM_GENERIC_DOMAINS if PM
select MAILBOX
+ select SOC_TI
select TI_MESSAGE_MANAGER
select TI_SCI_PROTOCOL
select TI_SCI_INTR_IRQCHIP
--
2.7.4
Re: [btrfs] ddf30cf03f: xfstests.generic.102.fail
On 2019/5/10 上午11:19, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: ddf30cf03fb53b9a0ad0f355a69dbedf416edde9 ("btrfs: extent-tree: Use
> btrfs_ref to refactor add_pinned_bytes()")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
Thanks for the info.
This explains why I have some unexpected ENOSPC error.
The cause is pretty aweful.
The offending patch relies completely btrfs_ref, but forgot that pinned
bytes can be minus, thus causing strange behavior.
I'll fix it soon.
Thanks for reporting again,
Qu
>
> in testcase: xfstests
> with following parameters:
>
> disk: 4HDD
> fs: btrfs
> test: generic-quick2
>
> test-description: xfstests is a regression test suite for xfs and other files
> ystems.
> test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 vm-snb-4G-727 5.1.0-rc7-00188-gddf30cf
> MKFS_OPTIONS -- /dev/vdb
> MOUNT_OPTIONS -- /dev/vdb /fs/scratch
>
> generic/088 2s
> generic/089 14s
> generic/090 1s
> generic/091 19s
> generic/092 3s
> generic/098 4s
> generic/100 18s
> generic/101 0s
> generic/102- output mismatch (see
> /lkp/benchmarks/xfstests/results//generic/102.out.bad)
> --- tests/generic/102.out2019-05-09 15:46:08.0 +0800
> +++ /lkp/benchmarks/xfstests/results//generic/102.out.bad2019-05-10
> 09:32:39.267250059 +0800
> @@ -1,21 +1,21 @@
> QA output created by 102
> wrote 838860800/838860800 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote 109576192/838860800 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> wrote 838860800/838860800 bytes at offset 0
> ...
> (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/102.out
> /lkp/benchmarks/xfstests/results//generic/102.out.bad' to see the entire
> diff)
> generic/103 1s
> generic/104 1s
> generic/105 0s
> generic/106 1s
> generic/107 1s
> generic/109 1s
> generic/120 16s
> generic/123 1s
> generic/124 4s
> generic/126 1s
> generic/129 6s
> generic/130 13s
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
> To reproduce:
>
> # build kernel
> cd linux
> cp config-5.1.0-rc7-00188-gddf30cf .config
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
>
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
> bin/lkp qemu -k -m modules.cgz job-script # job-script is
> attached in this email
>
>
>
>
> Thanks,
> Rong Chen
>
RE: [EXT] Re: [PATCH v6] arm64: dts: ls1088a: add one more thermal zone node
> -Original Message-
> From: Shawn Guo
> Sent: 2019年5月10日 11:14
> To: Andy Tang
> Cc: Leo Li ; robh...@kernel.org;
> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux...@vger.kernel.org; daniel.lezc...@linaro.org; rui.zh...@intel.com;
> edubez...@gmail.com
> Subject: [EXT] Re: [PATCH v6] arm64: dts: ls1088a: add one more thermal
> zone node
>
> Caution: EXT Email
>
> On Tue, Apr 23, 2019 at 10:25:07AM +0800, Yuantian Tang wrote:
> > Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core
> > cluster sensor is used to monitor the temperature of core and SoC
> > platform is for platform. The current dts only support the first sensor.
> > This patch adds the second sensor node to dts to enable it.
> >
> > Signed-off-by: Yuantian Tang
> > ---
> > v6:
> > - add cooling device map to cpu0-7 in platform node.
I like to explain a little. I think it makes sense that multiple thermal zone
map to same cooling device.
In this way, no matter which thermal zone raises a temp alarm, it can call
cooling device to chill out.
I also asked cpufreq maintainer about the cooling map issue, he think it would
be fine.
I have tested and no issue found.
Daniel, what's your thought?
Thanks,
Andy
>
> @Daniel, are you fine with this version?
>
> Shawn
--- Begin Message ---
WARNING: This email was created outside of NXP. DO NOT CLICK links or
attachments unless you recognize the sender and know the content is safe.
On 22-04-19, 07:09, Andy Tang wrote:
> Hi Viresh,
>
> Sorry to bother you. I have a question, hope I can get you help.
> Here it is:
>
> I want to add multiple "Thermal Zone" support in dts ( driver is ready).
> The final dts looks like below:
>
> thermal-zones {
> cpu_thermal: cpu-thermal {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = < 0>;
>
> trips {
> ccu_alert: ccu-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
> ccu_crit: ccu-crit {
> temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> cooling-maps {
> map0 {
> trip = <_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> };
> };
> };
> platform {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = < 1>;
> trips {
> plt_alert: plt-alert {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
> plt_crit: plt-crit {
> temperature = <95000>;
> hysteresis = <2000>;
> type = "critical";
> };
> };
> cooling-maps {
> map0 {
> trip = <_alert>;
> cooling-device =
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
>
Re: [PATCH 2/5] bio: fix improper use of smp_mb__before_atomic()
On Mon, Apr 29, 2019 at 10:14:58PM +0200, Andrea Parri wrote:
> This barrier only applies to the read-modify-write operations; in
> particular, it does not apply to the atomic_set() primitive.
>
> Replace the barrier with an smp_mb().
>
> Fixes: dac56212e8127 ("bio: skip atomic inc/dec of ->bi_cnt for most use
> cases")
> Cc: sta...@vger.kernel.org
> Reported-by: "Paul E. McKenney"
> Reported-by: Peter Zijlstra
> Signed-off-by: Andrea Parri
> Cc: Jens Axboe
> Cc: linux-bl...@vger.kernel.org
> ---
> include/linux/bio.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index e584673c18814..5becbafb84e8a 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -224,7 +224,7 @@ static inline void bio_cnt_set(struct bio *bio, unsigned
> int count)
> {
> if (count != 1) {
> bio->bi_flags |= (1 << BIO_REFFED);
> - smp_mb__before_atomic();
> + smp_mb();
> }
> atomic_set(>__bi_cnt, count);
> }
> --
> 2.7.4
>
Looks fine,
Reviewed-by: Ming Lei
Thanks,
Ming
[PATCH v2 2/3] mmc: sdhci_am654: Print error message if the DLL fails to lock
Print an error message and return if DLL fails to lock.
Signed-off-by: Faiz Abbas
---
drivers/mmc/host/sdhci_am654.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index 337c24b8f4a8..3ff949925127 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -137,6 +137,11 @@ static void sdhci_am654_set_clock(struct sdhci_host *host,
unsigned int clock)
ret = regmap_read_poll_timeout(sdhci_am654->base, PHY_STAT1,
val, val & DLLRDY_MASK, 1000,
100);
+ if (ret) {
+ dev_err(mmc_dev(host->mmc), "DLL failed to relock\n");
+ return;
+ }
+
sdhci_am654->dll_on = true;
}
}
--
2.19.2
[PATCH v2 0/3] Fix issues with phy configurations in am65x MMC driver
The following patches fix issues with phy configurations for sdhci_am654 driver. v2: 1. Split patch 1 into 2 separate patches. 2. Improved patch descriptions. Faiz Abbas (3): mmc: sdhci_am654: Improve line wrapping with regmap_*() calls mmc: sdhci_am654: Print error message if the DLL fails to lock mmc: sdhci_am654: Fix SLOTTYPE write drivers/mmc/host/sdhci_am654.c | 37 -- 1 file changed, 17 insertions(+), 20 deletions(-) -- 2.19.2
[PATCH v2 3/3] mmc: sdhci_am654: Fix SLOTTYPE write
In the call to regmap_update_bits() for SLOTTYPE, the mask and value fields are exchanged. Fix this. This didn't have any affect on the driver because this was a NOP and it was taking the correct value from the bootloader. Cc: stable Signed-off-by: Faiz Abbas --- drivers/mmc/host/sdhci_am654.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c index 3ff949925127..d0b20780dd0f 100644 --- a/drivers/mmc/host/sdhci_am654.c +++ b/drivers/mmc/host/sdhci_am654.c @@ -227,8 +227,8 @@ static int sdhci_am654_init(struct sdhci_host *host) if (host->mmc->caps & MMC_CAP_NONREMOVABLE) ctl_cfg_2 = SLOTTYPE_EMBEDDED; - regmap_update_bits(sdhci_am654->base, CTL_CFG_2, ctl_cfg_2, - SLOTTYPE_MASK); + regmap_update_bits(sdhci_am654->base, CTL_CFG_2, SLOTTYPE_MASK, + ctl_cfg_2); return sdhci_add_host(host); } -- 2.19.2
[PATCH v2 1/3] mmc: sdhci_am654: Improve line wrapping with regmap_*() calls
Line wrapping with the regmap_*() functions is way more conservative
than required by the 80 character rule. Expand the function calls out to
use less number of lines.
Signed-off-by: Faiz Abbas
---
drivers/mmc/host/sdhci_am654.c | 34 +-
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index a91c0b45c48d..337c24b8f4a8 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -88,8 +88,7 @@ static void sdhci_am654_set_clock(struct sdhci_host *host,
unsigned int clock)
int ret;
if (sdhci_am654->dll_on) {
- regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
- ENDLL_MASK, 0);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1, ENDLL_MASK, 0);
sdhci_am654->dll_on = false;
}
@@ -101,8 +100,7 @@ static void sdhci_am654_set_clock(struct sdhci_host *host,
unsigned int clock)
mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
val = (1 << OTAPDLYENA_SHIFT) |
(sdhci_am654->otap_del_sel << OTAPDLYSEL_SHIFT);
- regmap_update_bits(sdhci_am654->base, PHY_CTRL4,
- mask, val);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL4, mask, val);
switch (clock) {
case 2:
sel50 = 0;
@@ -120,8 +118,7 @@ static void sdhci_am654_set_clock(struct sdhci_host *host,
unsigned int clock)
/* Configure PHY DLL frequency */
mask = SEL50_MASK | SEL100_MASK;
val = (sel50 << SEL50_SHIFT) | (sel100 << SEL100_SHIFT);
- regmap_update_bits(sdhci_am654->base, PHY_CTRL5,
- mask, val);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL5, mask, val);
/* Configure DLL TRIM */
mask = DLL_TRIM_ICP_MASK;
val = sdhci_am654->trm_icp << DLL_TRIM_ICP_SHIFT;
@@ -129,20 +126,17 @@ static void sdhci_am654_set_clock(struct sdhci_host
*host, unsigned int clock)
/* Configure DLL driver strength */
mask |= DR_TY_MASK;
val |= sdhci_am654->drv_strength << DR_TY_SHIFT;
- regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
- mask, val);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1, mask, val);
/* Enable DLL */
- regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
- ENDLL_MASK, 0x1 << ENDLL_SHIFT);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1, ENDLL_MASK,
+ 0x1 << ENDLL_SHIFT);
/*
* Poll for DLL ready. Use a one second timeout.
* Works in all experiments done so far
*/
- ret = regmap_read_poll_timeout(sdhci_am654->base,
-PHY_STAT1, val,
-val & DLLRDY_MASK,
-1000, 100);
-
+ ret = regmap_read_poll_timeout(sdhci_am654->base, PHY_STAT1,
+ val, val & DLLRDY_MASK, 1000,
+ 100);
sdhci_am654->dll_on = true;
}
}
@@ -208,8 +202,7 @@ static int sdhci_am654_init(struct sdhci_host *host)
/* Reset OTAP to default value */
mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
- regmap_update_bits(sdhci_am654->base, PHY_CTRL4,
- mask, 0x0);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL4, mask, 0x0);
regmap_read(sdhci_am654->base, PHY_STAT1, );
if (~val & CALDONE_MASK) {
@@ -223,15 +216,14 @@ static int sdhci_am654_init(struct sdhci_host *host)
}
/* Enable pins by setting IO mux to 0 */
- regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
- IOMUX_ENABLE_MASK, 0);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1, IOMUX_ENABLE_MASK, 0);
/* Set slot type based on SD or eMMC */
if (host->mmc->caps & MMC_CAP_NONREMOVABLE)
ctl_cfg_2 = SLOTTYPE_EMBEDDED;
- regmap_update_bits(sdhci_am654->base, CTL_CFG_2,
- ctl_cfg_2, SLOTTYPE_MASK);
+ regmap_update_bits(sdhci_am654->base, CTL_CFG_2, ctl_cfg_2,
+ SLOTTYPE_MASK);
return sdhci_add_host(host);
}
--
2.19.2
Re: [PATCH v5 03/12] dt-binding: gce: add binding for gce subsys property
Hi, Rob, On Tue, 2019-05-07 at 12:41 -0500, Rob Herring wrote: > On Tue, May 07, 2019 at 04:13:46PM +0800, Bibby Hsieh wrote: > > tcmdq driver provide a function that get the relationship > > of sub system number from device node for client. > > add specification for #subsys-cells, mediatek,gce-subsys. > > > > Signed-off-by: Bibby Hsieh > > --- > > .../devicetree/bindings/mailbox/mtk-gce.txt | 15 --- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > index 1f7f8f2a3f49..8fd9479bc9f6 100644 > > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > @@ -21,11 +21,19 @@ Required properties: > > priority: Priority of GCE thread. > > atomic_exec: GCE processing continuous packets of commands in atomic > > way. > > +- #subsys-cells: Should be 3. > > + < subsys_number start_offset size> > > + phandle: Label name of a gce node. > > + subsys_number: specify the sub-system id which is corresponding > > + to the register address. > > + start_offset: the start offset of register address that GCE can access. > > + size: the total size of register address that GCE can access. > > Like the #event-cells, do you need this if it isn't variable? > Yes, we need. Because the start_offset and size will be a fix number when the chip was designed out. Those two informations will help us to check if the same register address was wrote by different user. The checking mechanism is designing... > > > > Required properties for a client device: > > - mboxes: Client use mailbox to communicate with GCE, it should have this > >property and list of phandle, mailbox specifiers. > > -- mediatek,gce-subsys: u32, specify the sub-system id which is > > corresponding > > +Optional propertier for a client device: > > +- mediatek,gce-client-reg: u32, specify the sub-system id which is > > corresponding > >to the register address. > > This isn't a u32, but a phandle + 3 cells (or a list of those). How many > entries can there be? Ok, I will fix it. > > > > > Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' > > @@ -40,6 +48,7 @@ Example: > > clocks = < CLK_INFRA_GCE>; > > clock-names = "gce"; > > #mbox-cells = <3>; > > + #subsys-cells = <3>; > > }; > > > > Example for a client device: > > @@ -48,9 +57,9 @@ Example for a client device: > > compatible = "mediatek,mt8173-mmsys"; > > mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>, > > < 1 CMDQ_THR_PRIO_LOWEST 1>; > > - mediatek,gce-subsys = ; > > mutex-event-eof = > CMDQ_EVENT_MUTEX1_STREAM_EOF>; > > - > > + mediatek,gce-client-reg = < SUBSYS_1400 0x3000 0x1000>, > > + < SUBSYS_1401 0x2000 0x100>; > > ... > > }; > > -- > > 2.18.0 > > -- Bibby
Re: [PATCH] ARM: imx_v6_v7_defconfig: Enable CONFIG_THERMAL_STATISTICS
On Wed, Apr 24, 2019 at 03:27:13AM +, Anson Huang wrote: > Enable CONFIG_THERMAL_STATISTICS to extend the sysfs interface > for thermal cooling devices and expose some useful statistics. > > Signed-off-by: Anson Huang I don't apply patch using base64 encoding. Shawn
Re: [PATCH] driver core: Fix use-after-free and double free on glue directory
Thanks for the comment, will check the patch and update. Regards Gaurav On 5/10/2019 4:52 AM, Benjamin Herrenschmidt wrote: On Thu, 2019-05-09 at 20:08 +0530, Gaurav Kohli wrote: Hi , Last patch will serialize the addition of child to parent directory, won't it affect performance. I doubt this is a significant issue, and there's already a global lock taken once or twice in that path, the fix is purely to make sure that the some locked section is used both for the lookup and the addition as the bug comes from the window in between those two operations allowing the object to be removed after it was "found". Cheers, Ben. Regards Gaurav On 5/4/2019 9:04 PM, Greg KH wrote: On Sat, May 04, 2019 at 10:47:07PM +0800, Muchun Song wrote: Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道： The basic idea yes, the whole bool *locked is horrid though. Wouldn't it work to have a get_device_parent_locked that always returns with the mutex held, or just move the mutex to the caller or something simpler like this ? Greg and Rafael, do you have any suggestions for this? Or you also agree with Ben? Ping guys ? This is worth fixing... I also agree with you. But Greg and Rafael seem to be high latency right now. It's in my list of patches to get to, sorry, hopefully will dig out of that next week with the buffer that the merge window provides me. thanks, greg k-h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v3] fs/proc: add VmTaskSize field to /proc/$$/status
Yury Norov writes:
> On Tue, May 07, 2019 at 08:54:31AM -0400, Rafael Aquini wrote:
>> On Mon, May 06, 2019 at 11:53:43AM -0400, Joel Savitz wrote:
>> > There is currently no easy and architecture-independent way to find the
>> > lowest unusable virtual address available to a process without
>> > brute-force calculation. This patch allows a user to easily retrieve
>> > this value via /proc//status.
>> >
>> > Using this patch, any program that previously needed to waste cpu cycles
>> > recalculating a non-sensitive process-dependent value already known to
>> > the kernel can now be optimized to use this mechanism.
>> >
>> > Signed-off-by: Joel Savitz
>> > ---
>> > Documentation/filesystems/proc.txt | 2 ++
>> > fs/proc/task_mmu.c | 2 ++
>> > 2 files changed, 4 insertions(+)
>> >
>> > diff --git a/Documentation/filesystems/proc.txt
>> > b/Documentation/filesystems/proc.txt
>> > index 66cad5c86171..1c6a912e3975 100644
>> > --- a/Documentation/filesystems/proc.txt
>> > +++ b/Documentation/filesystems/proc.txt
>> > @@ -187,6 +187,7 @@ read the file /proc/PID/status:
>> >VmLib: 1412 kB
>> >VmPTE:20 kb
>> >VmSwap:0 kB
>> > + VmTaskSize: 137438953468 kB
>> >HugetlbPages: 0 kB
>> >CoreDumping:0
>> >THP_enabled: 1
>> > @@ -263,6 +264,7 @@ Table 1-2: Contents of the status files (as of 4.19)
>> > VmPTE size of page table entries
>> > VmSwap amount of swap used by anonymous private data
>> > (shmem swap usage is not included)
>> > + VmTaskSize lowest unusable address in process virtual
>> > memory
>>
>> Can we change this help text to "size of process' virtual address space
>> memory" ?
>
> Agree. Or go in other direction and make it VmEnd
Yeah I think VmEnd would be clearer to folks who aren't familiar with
the kernel's usage of the TASK_SIZE terminology.
>> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> > index 95ca1fe7283c..0af7081f7b19 100644
>> > --- a/fs/proc/task_mmu.c
>> > +++ b/fs/proc/task_mmu.c
>> > @@ -74,6 +74,8 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
>> >seq_put_decimal_ull_width(m,
>> >" kB\nVmPTE:\t", mm_pgtables_bytes(mm) >> 10, 8);
>> >SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
>> > + seq_put_decimal_ull_width(m,
>> > + " kB\nVmTaskSize:\t", mm->task_size >> 10, 8);
>> >seq_puts(m, " kB\n");
>> >hugetlb_report_usage(m, mm);
>> > }
>
> I'm OK with technical part, but I still have questions not answered
> (or wrongly answered) in v1 and v2. Below is the very detailed
> description of the concerns I have.
>
> 1. What is the exact reason for it? Original version tells about some
> test that takes so much time that you were able to drink a cup of
> coffee before it was done. The test as you said implements linear
> search to find the last page and so is of O(n). If it's only for some
> random test, I think the kernel can survive without it. Do you have a
> real example of useful programs that suffer without this information?
>
>
> 2. I have nothing against taking breaks and see nothing weird if
> ineffective algorithms take time. On my system (x86, Ubuntu) the last
> mapped region according to /proc//maps is:
> ff60-ff601000 r-xp 00:00 0 [vsyscall]
> So to find the required address, we have to inspect 2559 pages. With a
> binary search it would take 12 iterations at max. If my calculation is
> wrong or your environment is completely different - please elaborate.
I agree it should not be hard to calculate, but at the same time it's
trivial for the kernel to export the information so I don't see why the
kernel shouldn't.
> 3. As far as I can see, Linux currently does not support dynamic
> TASK_SIZE. It means that for any platform+ABI combination VmTaskSize
> will be always the same. So VmTaskSize would be effectively useless waste
> of lines. In fact, TASK SIZE is compiler time information and should
> be exposed to user in headers. In discussion to v2 Rafael Aquini answered
> for this concern that TASK_SIZE is a runtime resolved macro. It's
> true, but my main point is: GCC knows what type of binary it compiles
> and is able to select proper value. We are already doing similar things
> where appropriate. Refer for example to my arm64/ilp32 series:
>
> arch/arm64/include/uapi/asm/bitsperlong.h:
> -#define __BITS_PER_LONG 64
> +#if defined(__LP64__)
> +/* Assuming __LP64__ will be defined for native ELF64's and not for ILP32. */
> +# define __BITS_PER_LONG 64
> +#elif defined(__ILP32__)
> +# define __BITS_PER_LONG 32
> +#else
> +# error "Neither LP64 nor ILP32: unsupported ABI in asm/bitsperlong.h"
> +#endif
>
> __LP64__ and __ILP32__ are symbols provided by GCC to distinguish
> between ABIs. So userspace is able to take proper __BITS_PER_LONG value
> at compile time, not at runtime. I think, you can do the same
Re: [PATCH 2/4] x86/kprobes: Fix frame pointer annotations
On Thu, 9 May 2019 13:43:16 -0400 Steven Rostedt wrote: > On Thu, May 09, 2019 at 09:20:06AM -0700, Andy Lutomirski wrote: > > > +END(call_to_exception_trampoline) > > > --- a/arch/x86/kernel/kprobes/core.c > > > +++ b/arch/x86/kernel/kprobes/core.c > > > @@ -731,29 +731,8 @@ asm( > > >".global kretprobe_trampoline\n" > > >".type kretprobe_trampoline, @function\n" > > >"kretprobe_trampoline:\n" > > > -/* We don't bother saving the ss register */ > > > -#ifdef CONFIG_X86_64 > > > -"pushq %rsp\n" > > > -"pushfq\n" > > > -SAVE_REGS_STRING > > > -"movq %rsp, %rdi\n" > > > -"call trampoline_handler\n" > > > -/* Replace saved sp with true return address. */ > > > -"movq %rax, 19*8(%rsp)\n" > > > -RESTORE_REGS_STRING > > > -"popfq\n" > > > -#else > > > -"pushl %esp\n" > > > -"pushfl\n" > > > -SAVE_REGS_STRING > > > -"movl %esp, %eax\n" > > > -"call trampoline_handler\n" > > > -/* Replace saved sp with true return address. */ > > > -"movl %eax, 15*4(%esp)\n" > > > -RESTORE_REGS_STRING > > > -"popfl\n" > > > -#endif > > > -"ret\n" > > > +"push trampoline_handler\n" > > > +"jmp call_to_exception_trampoline\n" > > >".size kretprobe_trampoline, .-kretprobe_trampoline\n" > > > ); > > > > > > Potentially minor nit: you’re doing popfl, but you’re not doing > > TRACE_IRQ_whatever. This makes me think that you should either add the > > tracing (ugh!) or you should maybe just skip the popfl. > > > Note, kprobes (and ftrace for that matter) are not saving flags for > interrupts, but because it must not modify the sign, zero and carry flags. Yes, optprobe also has to save and restore the flags. Above trampline is for kretprobe, which is placed at the function return, so we don't have to care about flags. Thanks, -- Masami Hiramatsu
Re: [PATCH v5 04/12] dt-binding: gce: add binding for gce event property
Hi, CK, On Wed, 2019-05-08 at 13:10 +0800, CK Hu wrote: > Hi, Bibby: > > On Tue, 2019-05-07 at 16:13 +0800, Bibby Hsieh wrote: > > Client hardware would send event to GCE hardware, > > mediatek,gce-event-names and mediatek,gce-events > > can be used to present the event. > > > > Signed-off-by: Bibby Hsieh > > --- > > Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > index 8fd9479bc9f6..76491f194c56 100644 > > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > @@ -35,6 +35,9 @@ Required properties for a client device: > > Optional propertier for a client device: > > - mediatek,gce-client-reg: u32, specify the sub-system id which is > > corresponding > >to the register address. > > +- mediatek,gce-event-names: the event name can be defined by user. > > gce-event is like an interrupt from client hardware to GCE hardware, we > do not give a name to an interrupt, so do we need to give a name for > gce-event? > Yes, we need to know the name of gce-ecent. The name can help users to figure out the problems when GCE meet the event time out errors. > Regards, > CK > > > +- mediatek,gce-events: u32, the event number defined in > > + 'dt-bindings/gce/mt8173-gce.h' or 'dt-binding/gce/mt8183-gce.h'. > > > > Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' > > or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, > > event ids. > > @@ -57,8 +60,10 @@ Example for a client device: > > compatible = "mediatek,mt8173-mmsys"; > > mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>, > > < 1 CMDQ_THR_PRIO_LOWEST 1>; > > - mutex-event-eof = > - CMDQ_EVENT_MUTEX1_STREAM_EOF>; > > + mediatek,gce-event-names = "rdma0_sof", > > + "rsz0_sof"; > > + mediatek,gce-events = , > > + ; > > mediatek,gce-client-reg = < SUBSYS_1400 0x3000 0x1000>, > > < SUBSYS_1401 0x2000 0x100>; > > ... > > -- Bibby
[PATCH] ubifs: Fix build error without CONFIG_UBIFS_FS_XATTR
Fix gcc build error while CONFIG_UBIFS_FS_XATTR
is not set
fs/ubifs/dir.o: In function `ubifs_unlink':
dir.c:(.text+0x260): undefined reference to `ubifs_purge_xattrs'
fs/ubifs/dir.o: In function `do_rename':
dir.c:(.text+0x1edc): undefined reference to `ubifs_purge_xattrs'
fs/ubifs/dir.o: In function `ubifs_rmdir':
dir.c:(.text+0x2638): undefined reference to `ubifs_purge_xattrs'
Reported-by: Hulk Robot
Fixes: 9ca2d7326444 ("ubifs: Limit number of xattrs per inode")
Signed-off-by: YueHaibing
---
fs/ubifs/ubifs.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 379b9f7..fd7f399 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -2015,13 +2015,17 @@ int ubifs_xattr_set(struct inode *host, const char
*name, const void *value,
size_t size, int flags, bool check_lock);
ssize_t ubifs_xattr_get(struct inode *host, const char *name, void *buf,
size_t size);
-int ubifs_purge_xattrs(struct inode *host);
#ifdef CONFIG_UBIFS_FS_XATTR
void ubifs_evict_xattr_inode(struct ubifs_info *c, ino_t xattr_inum);
+int ubifs_purge_xattrs(struct inode *host);
#else
static inline void ubifs_evict_xattr_inode(struct ubifs_info *c,
ino_t xattr_inum) { }
+static inline int ubifs_purge_xattrs(struct inode *host)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_UBIFS_FS_SECURITY
--
2.7.4
drivers/regulator/core.o: warning: objtool: regulator_count_voltages()+0x95: return with modified stack frame
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8ea5b2abd07e2280a332bd9c1a7f4dd15b9b6c13 commit: 37686b1353cfc30e127cef811959cdbcd0495d98 tracing: Improve "if" macro code generation date: 5 weeks ago config: x86_64-randconfig-b0-05100522 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 37686b1353cfc30e127cef811959cdbcd0495d98 # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): >> drivers/regulator/core.o: warning: objtool: regulator_count_voltages()+0x95: >> return with modified stack frame drivers/regulator/core.o: warning: objtool: regulator_count_voltages()+0x0: stack state mismatch: cfa1=7+32 cfa2=7+8 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v6] arm64: dts: ls1088a: add one more thermal zone node
On Tue, Apr 23, 2019 at 10:25:07AM +0800, Yuantian Tang wrote: > Ls1088a has 2 thermal sensors, core cluster and SoC platform. Core cluster > sensor is used to monitor the temperature of core and SoC platform is for > platform. The current dts only support the first sensor. > This patch adds the second sensor node to dts to enable it. > > Signed-off-by: Yuantian Tang > --- > v6: > - add cooling device map to cpu0-7 in platform node. @Daniel, are you fine with this version? Shawn
Re: [PATCH] arm64: defconfig: Enable FSL_EDMA driver
On Mon, Apr 22, 2019 at 01:30:56PM -0500, Li Yang wrote: > Enables the FSL EDMA driver by default. This also works around an issue > that imx-i2c driver keeps deferring the probe because of the DMA is not > ready. And currently the DMA engine framework can not correctly tell > if the DMA channels will truly become available later (it will never be > available if the DMA driver is not enabled). > > This will cause indefinite messages like below: > [3.335829] imx-i2c 218.i2c: can't get pinctrl, bus recovery not > supported > [3.344455] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000 uOhm) > [3.350917] lm90 0-004c: 0-004c supply vcc not found, using dummy regulator > [3.362089] imx-i2c 218.i2c: can't get pinctrl, bus recovery not > supported > [3.370741] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000 uOhm) > [3.377205] lm90 0-004c: 0-004c supply vcc not found, using dummy regulator > [3.388455] imx-i2c 218.i2c: can't get pinctrl, bus recovery not > supported > . > > Signed-off-by: Li Yang Applied, thanks.
Re: [PATCH] mm: vmscan: correct nr_reclaimed for THP
Yang Shi writes:
> On 5/9/19 7:12 PM, Huang, Ying wrote:
>> Yang Shi writes:
>>
>>> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
>>> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
>>> still gets inc'ed by one even though a whole THP (512 pages) gets
>>> swapped out.
>>>
>>> This doesn't make too much sense to memory reclaim. For example, direct
>>> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
>>> could fulfill it. But, if nr_reclaimed is not increased correctly,
>>> direct reclaim may just waste time to reclaim more pages,
>>> SWAP_CLUSTER_MAX * 512 pages in worst case.
>>>
>>> This change may result in more reclaimed pages than scanned pages showed
>>> by /proc/vmstat since scanning one head page would reclaim 512 base pages.
>>>
>>> Cc: "Huang, Ying"
>>> Cc: Johannes Weiner
>>> Cc: Michal Hocko
>>> Cc: Mel Gorman
>>> Cc: "Kirill A . Shutemov"
>>> Cc: Hugh Dickins
>>> Signed-off-by: Yang Shi
>>> ---
>>> I'm not quite sure if it was the intended behavior or just omission. I tried
>>> to dig into the review history, but didn't find any clue. I may miss some
>>> discussion.
>>>
>>> mm/vmscan.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>>> index fd9de50..7e026ec 100644
>>> --- a/mm/vmscan.c
>>> +++ b/mm/vmscan.c
>>> @@ -1446,7 +1446,11 @@ static unsigned long shrink_page_list(struct
>>> list_head *page_list,
>>> unlock_page(page);
>>> free_it:
>>> - nr_reclaimed++;
>>> + /*
>>> +* THP may get swapped out in a whole, need account
>>> +* all base pages.
>>> +*/
>>> + nr_reclaimed += (1 << compound_order(page));
>>> /*
>>> * Is there need to periodically free_page_list? It would
>> Good catch! Thanks!
>>
>> How about to change this to
>>
>>
>> nr_reclaimed += hpage_nr_pages(page);
>
> Either is fine to me. Is this faster than "1 << compound_order(page)"?
I think the readability is a little better. And this will become
nr_reclaimed += 1
if CONFIG_TRANSPARENT_HUAGEPAGE is disabled.
Best Regards,
Huang, Ying
>>
>> Best Regards,
>> Huang, Ying
Re: [PATCH v1 3/3] clk: qcom: rcg: update the DFS macro for RCG
Hello Stephen,
Thanks for the review.
On 5/9/2019 10:57 PM, Stephen Boyd wrote:
Quoting Taniya Das (2019-05-08 11:24:55)
Update the init data name for each of the dynamic frequency switch
controlled clock associated with the RCG clock name, so that it can be
generated as per the hardware plan. Thus update the macro accordingly.
Signed-off-by: Taniya Das
This patch doesn't make any sense to me.
---
drivers/clk/qcom/clk-rcg.h| 2 +-
drivers/clk/qcom/gcc-sdm845.c | 96 +--
2 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 5562f38..e40e8f8 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -171,7 +171,7 @@ struct clk_rcg_dfs_data {
};
#define DEFINE_RCG_DFS(r) \
- { .rcg = ##_src, .init = ##_init }
+ { .rcg = , .init = ##_init }
Why do we need to rename the init data?
We want to manage the init data as the clock source name, so that we
could manage to auto generate our code. So that we do not have to
re-name the clock init data manually if the DFS source names gets
updated at any point of time.
extern int qcom_cc_register_rcg_dfs(struct regmap *regmap,
const struct clk_rcg_dfs_data *rcgs,
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index 7131dcf..a76178b 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -408,7 +408,7 @@ enum {
{ }
};
-static struct clk_init_data gcc_qupv3_wrap0_s0_clk_init = {
+static struct clk_init_data gcc_qupv3_wrap0_s0_clk_src_init = {
.name = "gcc_qupv3_wrap0_s0_clk_src",
.parent_names = gcc_parent_names_0,
.num_parents = 4,
@@ -3577,22 +3577,22 @@ enum {
MODULE_DEVICE_TABLE(of, gcc_sdm845_match_table);
static const struct clk_rcg_dfs_data gcc_dfs_clocks[] = {
- DEFINE_RCG_DFS(gcc_qupv3_wrap0_s0_clk),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s0_clk_src),
I've trimmed the above to try and see what's changed but it doesn't make
sense still.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
[PATCH 1/3] Input: apanel: avoid panic if ioreamp fails
If ioremap fails, NULL pointer dereference will happen and
leading to a kernel panic when access the virtual address
in check_signature().
Fix it by check the return value of ioremap.
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
---
drivers/input/misc/apanel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/apanel.c b/drivers/input/misc/apanel.c
index c1e66f45d552..1c7262ad4b5b 100644
--- a/drivers/input/misc/apanel.c
+++ b/drivers/input/misc/apanel.c
@@ -259,7 +259,9 @@ static int __init apanel_init(void)
unsigned char i2c_addr;
int found = 0;
- bios = ioremap(0xF, 0x1); /* Can't fail */
+ bios = ioremap(0xF, 0x1);
+ if (!bios)
+ return -ENOMEM;
p = bios_signature(bios);
if (!p) {
--
2.20.1
[PATCH 2/3] Input: wistron_btns: avoid panic if ioreamp fails
If ioremap fails, NULL pointer dereference will happen and
leading to a kernel panic when access the virtual address
in check_signature().
Fix it by check the return value of ioremap.
Cc: Dmitry Torokhov
Cc: Miloslav Trmac
Cc: Wolfram Sang
Cc: linux-in...@vger.kernel.org
Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
---
drivers/input/misc/wistron_btns.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/wistron_btns.c
b/drivers/input/misc/wistron_btns.c
index 43e67f546366..a82ec3d102b4 100644
--- a/drivers/input/misc/wistron_btns.c
+++ b/drivers/input/misc/wistron_btns.c
@@ -107,7 +107,10 @@ static int __init map_bios(void)
ssize_t offset;
u32 entry_point;
- base = ioremap(0xF, 0x1); /* Can't fail */
+ base = ioremap(0xF, 0x1);
+ if (!base)
+ return -ENOMEM;
+
offset = locate_wistron_bios(base);
if (offset < 0) {
printk(KERN_ERR "wistron_btns: BIOS entry point not found\n");
--
2.20.1
[PATCH 3/3] i2c: i801: avoid panic if ioreamp fails
If ioremap fails, NULL pointer dereference will happen and
leading to a kernel panic when access the virtual address
in check_signature().
Fix it by check the return value of ioremap.
Cc: Jean Delvare
Cc: Wolfram Sang
Cc: linux-...@vger.kernel.org
Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
---
drivers/i2c/busses/i2c-i801.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 679c6c41f64b..fc6ccb8aba17 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1068,7 +1068,10 @@ static void __init input_apanel_init(void)
void __iomem *bios;
const void __iomem *p;
- bios = ioremap(0xF, 0x1); /* Can't fail */
+ bios = ioremap(0xF, 0x1);
+ if (!base)
+ return -ENOMEM;
+
p = bios_signature(bios);
if (p) {
/* just use the first address */
--
2.20.1
Re: [PATCH 1/2] soc: imx-sc: add i.MX system controller soc driver support
On Mon, Apr 22, 2019 at 08:48:56AM +, Leonard Crestez wrote: > On 4/22/2019 9:46 AM, Anson Huang wrote: > >> -Original Message- > >> From: Anson Huang > >>> From: Shawn Guo [mailto:shawn...@kernel.org] > >>> On Sun, Apr 21, 2019 at 03:40:00PM +0800, Shawn Guo wrote: > On Thu, Apr 11, 2019 at 06:49:12AM +, Anson Huang wrote: > > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > > inside, the system controller is in charge of controlling power, > > clock and fuse etc.. > > > > This patch adds i.MX system controller soc driver support, Linux > > kernel has to communicate with system controller via MU (message > > unit) IPC to get soc revision, uid etc.. > > > > With this patch, soc info can be read from sysfs: > > > > drivers/soc/imx/Kconfig | 7 ++ > > drivers/soc/imx/Makefile | 1 + > > drivers/soc/imx/soc-imx-sc.c | 220 > > +++ > > 3 files changed, 228 insertions(+) create mode 100644 > > drivers/soc/imx/soc-imx-sc.c > > Rather than creating a new driver, please take a look at Abel's > generic > i.MX8 SoC driver, and see if it can be extended to cover i.MX8QXP. > >> > >> Got it, I didn't notice that this patch bas been accepted, I will redo the > >> patch > >> based on it, thanks. > > > > I have sent the new patch set to support i.MX8QXP SoC revision based on > > generic i.MX8 > > SoC driver, however, the Kconfig modification is NOT good, it may break > > i.MX8MQ if IMX_SCU > > is NOT enabled, although we can add some warp function for SCU firmware API > > call to fix it, > > but after further thought and discussion with Dong Aisheng, I think we may > > need to roll back to > > use this patch series to create a new SoC driver dedicated for i.MX8 SoCs > > with system controller inside, such as i.MX8QXP, i.MX8QM etc., the reason > > are as below: > > > > For i.MX8MQ/i.MX8MM: > > 1. SoC driver does NOT depends on i.MX SCU firmware, so no need to use > > platform driver > > probe model, just device_init phase call is good enough; > > 2. The SoC driver no need to depends on IMX_SCU, so it can be always > > built in, no need to > > check IMX_SCU config; > > 3. The fuse check for CPU speed grading, HDCP status, NoC settings etc. > > could be added to this driver, > > but they are ONLY for i.MX8MQ/i.MX8MM etc.. > > For i.MX8QXP/i.MX8QM: > > 1. SoC driver MUST depends on IMX_SCU; > > 2. MUST use platform model to support defer probe; > > 3. No fuse check for CPU speed grading. > > > > So, I guess the reused code for i.MX8MQ and i.MX8QXP is ONLY those part of > > creating SoC id device node (less than > > 30% I think), all other functions are implemented in total different ways, > > that is why I created the imx_sc_soc driver > > in this patch series, so do you think we can add new SoC driver for i.MX8 > > SoC with SCU inside? Putting 2 different architecture > > SoCs' driver into 1 file looks like NOT making enough sense. > > +1 for separate SOC driver. The 8mq/8mm and 8qm/8qxp families are very > different, they just happen to share the imx8 prefix. > > It makes sense to allow people to compile one without the other and this > is easier with distinct SOC drivers. Leonard, Abel, Can you guys help review the patch? Thanks. Shawn
Re: [git pull] vfs.git braino fix
The pull request you sent on Fri, 10 May 2019 03:33:33 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8ea5b2abd07e2280a332bd9c1a7f4dd15b9b6c13 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH] staging: wlan-ng: collect return status without variable
err and result variables are declared to collect return status
of prism2_domibset_uint32.
Check return status in if loop and return directly.
Rearragne code such that we can avoid declaring these variables.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/wlan-ng/cfg80211.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 8a862f7..5dad5ac 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -231,17 +231,12 @@ static int prism2_set_default_key(struct wiphy *wiphy,
struct net_device *dev,
{
struct wlandevice *wlandev = dev->ml_priv;
- int err = 0;
- int result = 0;
-
- result = prism2_domibset_uint32(wlandev,
- DIDMIB_DOT11SMT_PRIVACYTABLE_WEPDEFAULTKEYID,
- key_index);
-
- if (result)
- err = -EFAULT;
-
- return err;
+ if (prism2_domibset_uint32(wlandev,
+ DIDMIB_DOT11SMT_PRIVACYTABLE_WEPDEFAULTKEYID,
+ key_index))
+ return -EFAULT;
+ else
+ return 0;
}
static int prism2_get_station(struct wiphy *wiphy, struct net_device *dev,
--
2.7.4
Re: [PATCH v2 17/18] fpga: dfl: fme: add global error reporting support
On Thu, May 09, 2019 at 11:27:36AM -0500, Alan Tull wrote:
> On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote:
>
> Hi Hao,
>
> The changes look good. There's one easy to fix thing that Greg has
> pointed out recently on another patch (below).
>
> >
> > This patch adds support for global error reporting for FPGA
> > Management Engine (FME), it introduces sysfs interfaces to
> > report different error detected by the hardware, and allow
> > user to clear errors or inject error for testing purpose.
> >
> > Signed-off-by: Luwei Kang
> > Signed-off-by: Ananda Ravuri
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
>
> Acked-by: Alan Tull
>
> > ---
> > v2: fix issues found in sysfs doc.
> > fix returned error code issues for writable sysfs interfaces.
> > (use -EINVAL if input doesn't match error code)
> > reorder the sysfs groups in code.
>
> > +static ssize_t revision_show(struct device *dev, struct device_attribute
> > *attr,
> > +char *buf)
> > +{
> > + struct device *err_dev = dev->parent;
> > + void __iomem *base;
> > +
> > + base = dfl_get_feature_ioaddr_by_id(err_dev,
> > FME_FEATURE_ID_GLOBAL_ERR);
> > +
> > + return scnprintf(buf, PAGE_SIZE, "%u\n",
> > dfl_feature_revision(base));
>
> Greg is discouraging use of scnprintf for sysfs attributes where it's
> not needed [1].
>
> Please fix this up the attributes added in this patchset. Besides
> that, looks good, I added my Ack.
Sure, will fix them in the next patchset.
thanks a lot!
Hao
>
> Alan
>
> > +}
> > +static DEVICE_ATTR_RO(revision);
>
> [1] https://lkml.org/lkml/2019/4/25/1050
Re: [RFC][PATCH] ftrace/x86: Remove mcount support
On Thu, 9 May 2019 15:49:02 -0400 Steven Rostedt wrote: > diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h > index cf350639e76d..287f1f7b2e52 100644 > --- a/arch/x86/include/asm/ftrace.h > +++ b/arch/x86/include/asm/ftrace.h > @@ -3,12 +3,10 @@ > #define _ASM_X86_FTRACE_H > > #ifdef CONFIG_FUNCTION_TRACER > -#ifdef CC_USING_FENTRY > -# define MCOUNT_ADDR ((unsigned long)(__fentry__)) > -#else > -# define MCOUNT_ADDR ((unsigned long)(mcount)) > -# define HAVE_FUNCTION_GRAPH_FP_TEST > +#ifndef CC_USING_FENTRY > +# error Compiler does not support fentry? > #endif > +# define MCOUNT_ADDR ((unsigned long)(__fentry__)) > #define MCOUNT_INSN_SIZE 5 /* sizeof mcount call */ > > #ifdef CONFIG_DYNAMIC_FTRACE Failed my tests. :-( In arch/x86/Kconfig ... select HAVE_FENTRY if X86_64 || DYNAMIC_FTRACE Bah! I need to work a little on this patch. I need to implement fentry in the !DYNAMIC_FTRACE code of x86_32 first. Shouldn't be too hard, but still. I could also just force DYNAMIC_FTRACE to be 'y' for x86_32 if CONFIG_FUNCTION_TRACER is set. The only reason I still support static FTRACE on x86 is because I use it to test !DYNAMIC_FTRACE generic code, because there's still some archs that only support the !DYNAMIC_FTRACE function tracer. -- Steve
Re: [GIT PULL] Driver core patches for 5.2-rc1
On Thu, May 09, 2019 at 01:47:54PM -0700, Linus Torvalds wrote: > [ Ok, this may look irrelevant to people, but I actually notice this > because I do quick rebuilds *all* the time, so the 30s vs 41s > difference is actually something I reacted to and then tried to figure > out... ] > > On Tue, May 7, 2019 at 10:59 AM Greg KH wrote: > > > > Joel Fernandes (Google) (2): > > Provide in-kernel headers to make extending kernel easier > > Joel and Masahiro, > this commit does annoying things. It's a small thing, but it ends up > grating on my kernel rebuild times, so I hope somebody can take a look > at it.. > > Try building a kernel with no changes, and it shouldn't re-link. > > HOWEVER. > > If you re-make the config in between, the kernel/kheaders_data.tar.xz > is re-generated too. I think it checks timestamps despite having that > "CHK" phase that should verify just contents. > > I think the kernel/config_data.gz rules do the same thing, judging by > the output. > > I use "make allmodconfig" to re-generate the same kernel config, which > triggers this. The difference between "nothing changed" and "rerun > 'make allmodconfig' and nothing _still_ should have changed" is quite > stark: [snip] > No, this isn't the end of the world, but if somebody sees a simple > solution to avoid that extra ten seconds, I'd appreciate it. Hi Linus, The following patch should fix the issue. The patch depends on [1] though. So that will have to be pulled first (which I believe Greg is going to pull soon since it is in his pipeline, and Steven Rostedt already Acked it) [1] https://lore.kernel.org/patchwork/patch/1070199/ For the below patch which fixes this issue, I have tested it and it fixes the allmodconfig issue. Could you try it out as well? As mentioned above, the patch at [1] should be applied first. Thanks a lot and let me know how it goes. (I am going to be on a long haul flight shortly so I may not be available for next 24-48 hours but will be there after, thanks). ---8<--- From: "Joel Fernandes (Google)" Subject: [PATCH] gen_kheaders: Do not regenerate archive if config is not changed Linus reported that allmodconfig config was causing the kheaders archive to be regenerated even though the config is the same. This is due to the fact that the generated config header files are rewritten even if they were the same from a previous run. To fix the issue, we ignore changes to these files and use md5sum on auto.conf to determine if the config really changed. And regenerate the header archive if it has. Reported-by: Linus Torvalds Signed-off-by: Joel Fernandes (Google) --- kernel/gen_kheaders.sh | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh index 581b83534587..f621242037f4 100755 --- a/kernel/gen_kheaders.sh +++ b/kernel/gen_kheaders.sh @@ -33,7 +33,7 @@ arch/$SRCARCH/include/ # Uncomment it for debugging. # iter=1 # if [ ! -f /tmp/iter ]; then echo 1 > /tmp/iter; -# else;iter=$(($(cat /tmp/iter) + 1)); fi +# else iter=$(($(cat /tmp/iter) + 1)); fi # find $src_file_list -type f | xargs ls -lR > /tmp/src-ls-$iter # find $obj_file_list -type f | xargs ls -lR > /tmp/obj-ls-$iter @@ -43,16 +43,27 @@ arch/$SRCARCH/include/ pushd $kroot > /dev/null src_files_md5="$(find $src_file_list -type f | grep -v "include/generated/compile.h" | + grep -v "include/generated/autoconf.h" | + grep -v "include/config/auto.conf" | + grep -v "include/config/auto.conf.cmd" | + grep -v "include/config/tristate.conf" | xargs ls -lR | md5sum | cut -d ' ' -f1)" popd > /dev/null obj_files_md5="$(find $obj_file_list -type f | grep -v "include/generated/compile.h" | + grep -v "include/generated/autoconf.h" | + grep -v "include/config/auto.conf" | + grep -v "include/config/auto.conf.cmd" | + grep -v "include/config/tristate.conf" | xargs ls -lR | md5sum | cut -d ' ' -f1)" +config_md5="$(md5sum include/config/auto.conf | cut -d ' ' -f1)" + if [ -f $tarfile ]; then tarfile_md5="$(md5sum $tarfile | cut -d ' ' -f1)"; fi if [ -f kernel/kheaders.md5 ] && [ "$(cat kernel/kheaders.md5|head -1)" == "$src_files_md5" ] && [ "$(cat kernel/kheaders.md5|head -2|tail -1)" == "$obj_files_md5" ] && + [ "$(cat kernel/kheaders.md5|head -3|tail -1)" == "$config_md5" ] && [ "$(cat kernel/kheaders.md5|tail -1)" == "$tarfile_md5" ]; then exit fi @@ -82,8 +93,9 @@ find $cpio_dir -type f -print0 | tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null -echo "$src_files_md5" > kernel/kheaders.md5 +echo "$src_files_md5" >
[PATCH] ASoC: SOF: Fix build error with CONFIG_SND_SOC_SOF_NOCODEC=m
Fix gcc build error while CONFIG_SND_SOC_SOF_NOCODEC=m
sound/soc/sof/core.o: In function `snd_sof_device_probe':
core.c:(.text+0x4af): undefined reference to `sof_nocodec_setup'
Change SND_SOC_SOF_NOCODEC to bool to fix this.
Reported-by: Hulk Robot
Fixes: c16211d6226d ("ASoC: SOF: Add Sound Open Firmware driver core")
Signed-off-by: YueHaibing
---
sound/soc/sof/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig
index b204c65..9c280c9 100644
--- a/sound/soc/sof/Kconfig
+++ b/sound/soc/sof/Kconfig
@@ -44,7 +44,7 @@ config SND_SOC_SOF_OPTIONS
if SND_SOC_SOF_OPTIONS
config SND_SOC_SOF_NOCODEC
- tristate "SOF nocodec mode Support"
+ bool "SOF nocodec mode Support"
help
This adds support for a dummy/nocodec machine driver fallback
option if no known codec is detected. This is typically only
--
2.7.4
Re: kobject_init_and_add() confusion
On Wed, May 01, 2019 at 09:54:16AM +0200, Rafael J. Wysocki wrote:
> On Wed, May 1, 2019 at 1:38 AM Tobin C. Harding wrote:
> >
> > Hi,
> >
> > Looks like I've created a bit of confusion trying to fix memleaks in
> > calls to kobject_init_and_add(). Its spread over various patches and
> > mailing lists so I'm starting a new thread and CC'ing anyone that
> > commented on one of those patches.
> >
> > If there is a better way to go about this discussion please do tell me.
> >
> > The problem
> > ---
> >
> > Calls to kobject_init_and_add() are leaking memory throughout the kernel
> > because of how the error paths are handled.
> >
> > The solution
> >
> >
> > Write the error path code correctly.
> >
> > Example
> > ---
> >
> > We have samples/kobject/kobject-example.c but it uses
> > kobject_create_and_add(). I thought of adding another example file here
> > but could not think of how to do it off the top of my head without being
> > super contrived. Can add this to the TODO list if it will help.
> >
> > Here is an attempted canonical usage of kobject_init_and_add() typical
> > of the code that currently is getting it wrong. This is the second time
> > I've written this and the first time it was wrong even after review (you
> > know who you are, you are definitely buying the next round of drinks :)
> >
> >
> > Assumes we have an object in memory already that has the kobject
> > embedded in it. Variable 'kobj' below would typically be >kobj
> >
> >
> > void fn(void)
> > {
> > int ret;
> >
> > ret = kobject_init_and_add(kobj, ktype, NULL, "foo");
> > if (ret) {
> > /*
> > * This means kobject_init() has succeeded
> > * but kobject_add() failed.
> > */
> > goto err_put;
> > }
> >
> > ret = some_init_fn();
> > if (ret) {
> > /*
> > * We need to wind back kobject_add() AND
> > kobject_put().
>
> kobject_add() and kobject_init() I suppose?
>
> > * kobject_add() incremented the refcount in
> > * kobj->parent, that needs to be decremented THEN
> > we need
> > * the call to kobject_put() to decrement the
> > refcount of kobj.
> > */
>
> So actually, if you look at kobject_cleanup(), it calls kobject_del()
> if kobj->state_in_sysfs is set.
>
> Now, if you look at kobject_add_internal(), it sets
> kobj->state_in_sysfs when about to return 0 (success).
>
> Therefore calling kobject_put() without the preceding kobject_del() is
> not a bug technically, even though it will trigger the "auto cleanup
> kobject_del" message with debug enabled.
>
> > goto err_del;
> > }
> >
> > ret = some_other_init_fn();
> > if (ret)
> > goto other_err;
> >
> > kobject_uevent(kobj, KOBJ_ADD);
> > return 0;
> >
> > other_err:
> > other_clean_up_fn();
> > err_del:
> > kobject_del(kobj);
> > err_put:
> > kobject_put(kobj);
> >
> > return ret;
> > }
> >
> >
> > Have I got this correct?
> >
> > TODO
> >
> >
> > - Fix all the callsites to kobject_init_and_add()
> > - Further clarify the function docstring for kobject_init_and_add()
> > [perhaps]
> > - Add a section to Documentation/kobject.txt [optional]
> > - Add a sample usage file under samples/kobject [optional]
>
> The plan sounds good to me, but there is one thing to note IMO:
> kobject_cleanup() invokes the ->release() callback for the ktype, so
> these callbacks need to be able to cope with kobjects after a failing
> kobject_add() which may not be entirely obvious to developers
> introducing them ATM.
It has taken a while for this to soak in. This is actually quite an
insidious issue. If I give an example and perhaps we can come to a
solution. This example is based on the code (and assumptions) in
mm/slub.c
If a developer has an object that they wish to add to sysfs they go
ahead and embed a kobject in it. Correctly set up a ktype including
release function that just frees the object (using container of). Now
assume that the object is already set up and in use when we go to set up
the sysfs entry. If kobject_init_and_add() fails and we correctly call
kobject_put() the containing object will be free'd. Yet the calling
code may not be done with the object, more to the point just because
sysfs setup fails the object is now unusable. Besides the interesting
theoretical discussion this means we cannot just go and willy-nilly add
calls to kobject_put() in the error path of kobject_init_and_add() if
the original code was not written under the
[git pull] vfs.git braino fix
Fix for umount -l/mount --move race caught by syzbot yesterday... The following changes since commit 80f232121b69cc69a31ccb2b38c1665d770b0710: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2019-05-07 22:03:58 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes for you to fetch changes up to 05883eee857eab4693e7d13ebab06716475c5754: do_move_mount(): fix an unsafe use of is_anon_ns() (2019-05-09 02:32:50 -0400) Al Viro (1): do_move_mount(): fix an unsafe use of is_anon_ns() fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [RFC][PATCH] ftrace/x86: Remove mcount support
On Thu, 9 May 2019 15:14:30 -0500 Josh Poimboeuf wrote: > > Signed-off-by: Steven Rostedt (VMware) > > --- > > arch/x86/include/asm/ftrace.h| 8 +++ > > arch/x86/include/asm/livepatch.h | 3 --- > > arch/x86/kernel/ftrace_32.S | 36 +--- > > arch/x86/kernel/ftrace_64.S | 28 + > > 4 files changed, 9 insertions(+), 66 deletions(-) > > I was wondering why you didn't do s/mcount/fentry/ everywhere, but I > guess it's because mcount is still used by other arches, so it still has > a generic meaning tree-wide, right? Yes, fentry works nicely when you have a single instruction that pushes the return address on the stack and then jumps to another location. It's much trickier to implement with link registers. There's a few different implementations for other archs, but mcount happens to be the one supported by most. > > Anyway it's nice to finally see this cruft disappear. > > Acked-by: Josh Poimboeuf Thanks! -- Steve
Re: [RFC][PATCH] ftrace/x86: Remove mcount support
On Thu, 9 May 2019 13:12:55 -0700
Linus Torvalds wrote:
> On Thu, May 9, 2019 at 12:49 PM Steven Rostedt wrote:
> >
> > diff --git a/arch/x86/include/asm/livepatch.h
> > b/arch/x86/include/asm/livepatch.h
> > index ed80003ce3e2..2f2bdf0662f8 100644
> > --- a/arch/x86/include/asm/livepatch.h
> > +++ b/arch/x86/include/asm/livepatch.h
> > @@ -26,9 +26,6 @@
> >
> > static inline int klp_check_compiler_support(void)
> > {
> > -#ifndef CC_USING_FENTRY
> > - return 1;
> > -#endif
> > return 0;
> > }
>
> Please remove this entirely.
>
> There are now three copies of klp_check_compiler_support(), and all
> three are now trivial "return 0" functions.
>
> Remove the whole thing, and remove the single use in kernel/livepatch/core.c.
>
> The only reason for this function existing was literally "mcount isn't
> good enough", so with mcount removed, the function should be removed
> too.
>
As this patch is simply a "remove mcount" patch, I'd like to have the
removal of klp_check_compiler_support() be a separate patch.
Jiri or Josh, care to send a patch on top of this one?
Thanks!
-- Steve
Re: [PATCH 5/7] lib: rework bitmap_parse()
Hi Andy,
Thanks for thorough review.
On Wed, May 08, 2019 at 11:46:32AM +0300, Andy Shevchenko wrote:
> On Tue, Apr 30, 2019 at 06:06:34PM -0700, Yury Norov wrote:
> > bitmap_parse() is ineffective and full of opaque variables and opencoded
> > parts. It leads to hard understanding and usage of it. This rework
> > includes:
> > - remove bitmap_shift_left() call from the cycle. Now it makes the
> >complexity of the algorithm as O(nbits^2). In the suggested approach
> >the input string is parsed in reverse direction, so no shifts needed;
> > - relax requirement on a single comma and no white spaces between chunks.
> >It is considered useful in scripting, and it aligns with
> >bitmap_parselist();
> > - split bitmap_parse() to small readable helpers;
> > - make an explicit calculation of the end of input line at the
> >beginning, so users of the bitmap_parse() won't bother doing this.
>
> > +static inline bool in_str(const char *start, const char *ptr)
> > +{
> > + return start <= ptr;
> > +}
> > +
>
> The explicit use of the conditional is better.
>
> --
> With Best Regards,
> Andy Shevchenko
I still think that is_str() is more verbose, but it's minor issue
anyways, so I obey. Below is the patch that removes the function.
It's up to Andrew finally, either apply it or not.
Thanks,
Yury
>From 7438c15a0b165032a3e5a6d87daabe877dc8cbc8 Mon Sep 17 00:00:00 2001
From: Yury Norov
Date: Thu, 9 May 2019 17:54:23 -0700
Subject: [PATCH] lib: opencode in_str()
Signed-off-by: Yury Norov
---
lib/bitmap.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index ebcf4700ebed..ecf93d2982a5 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -454,11 +454,6 @@ static inline bool end_of_region(char c)
return __end_of_region(c) || end_of_str(c);
}
-static inline bool in_str(const char *start, const char *ptr)
-{
- return start <= ptr;
-}
-
/*
* The format allows commas and whitespases at the beginning
* of the region.
@@ -473,7 +468,7 @@ static const char *bitmap_find_region(const char *str)
static const char *bitmap_find_region_reverse(const char *start, const char
*end)
{
- while (in_str(start, end) && __end_of_region(*end))
+ while (start <= end && __end_of_region(*end))
end--;
return end;
@@ -618,7 +613,7 @@ static const char *bitmap_get_x32_reverse(const char *start,
ret |= c << i;
- if (!in_str(start, end) || __end_of_region(*end))
+ if (start > end || __end_of_region(*end))
goto out;
}
@@ -653,7 +648,7 @@ int bitmap_parse(const char *start, unsigned int buflen,
u32 *bitmap = (u32 *)maskp;
int unset_bit;
- while (in_str(start, (end = bitmap_find_region_reverse(start, end {
+ while (start <= (end = bitmap_find_region_reverse(start, end))) {
if (!chunks--)
return -EOVERFLOW;
--
2.17.1
Re: [PATCH v2 2/3] iio: dps310: Temperature measurement errata
On Thu, May 9, 2019 at 11:17 PM Eddie James wrote:
>
>
> On 5/8/19 10:09 PM, Matt Ranostay wrote:
> > On Thu, May 9, 2019 at 3:36 AM Eddie James wrote:
> >> From: Christopher Bostic
> >>
> >> Add a manufacturer's suggested workaround to deal with early revisions
> >> of chip that don't indicate correct temperature. Readings can be in the
> >> ~60C range when they should be in the ~20's.
> >>
> >> Signed-off-by: Christopher Bostic
> >> Signed-off-by: Joel Stanley
> >> Signed-off-by: Eddie James
> >> ---
> >> drivers/iio/pressure/dps310.c | 51
> >> ++-
> >> 1 file changed, 50 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> >> index 7afaa88..c42808e 100644
> >> --- a/drivers/iio/pressure/dps310.c
> >> +++ b/drivers/iio/pressure/dps310.c
> >> @@ -221,6 +221,9 @@ static bool dps310_is_writeable_reg(struct device
> >> *dev, unsigned int reg)
> >> case DPS310_MEAS_CFG:
> >> case DPS310_CFG_REG:
> >> case DPS310_RESET:
> >> + case 0x0e:
> >> + case 0x0f:
> >> + case 0x62:
> > What is with the magic values? Are they not documented to what they
> > are, and hence not defining enum values for them?
> >
> > - Matt
>
>
> Thats correct. These don't show up in the data sheet so I left them as
> raw values. Chris, do you know what the source for these values was?
Please at least make a comment in the code stating as much.
- Matt
>
> Thanks,
>
> Eddie
>
>
> >
> >> return true;
> >> default:
> >> return false;
> >> @@ -237,6 +240,7 @@ static bool dps310_is_volatile_reg(struct device *dev,
> >> unsigned int reg)
> >> case DPS310_TMP_B1:
> >> case DPS310_TMP_B2:
> >> case DPS310_MEAS_CFG:
> >> + case 0x32:
> >> return true;
> >> default:
> >> return false;
> >> @@ -314,7 +318,7 @@ static int dps310_read_raw(struct iio_dev *iio,
> >> .writeable_reg = dps310_is_writeable_reg,
> >> .volatile_reg = dps310_is_volatile_reg,
> >> .cache_type = REGCACHE_RBTREE,
> >> - .max_register = 0x29,
> >> + .max_register = 0x62,
> >> };
> >>
> >> static const struct iio_info dps310_info = {
> >> @@ -322,6 +326,47 @@ static int dps310_read_raw(struct iio_dev *iio,
> >> .write_raw = dps310_write_raw,
> >> };
> >>
> >> +/*
> >> + * Some verions of chip will read temperatures in the ~60C range when
> >> + * its actually ~20C. This is the manufacturer recommended workaround
> >> + * to correct the issue.
> >> + */
> >> +static int dps310_temp_workaround(struct dps310_data *data)
> >> +{
> >> + int r, reg;
> >> +
> >> + r = regmap_read(data->regmap, 0x32, );
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + /*
> >> +* If bit 1 is set then the device is okay, and the workaround
> >> does not
> >> +* need to be applied
> >> +*/
> >> + if (reg & BIT(1))
> >> + return 0;
> >> +
> >> + r = regmap_write(data->regmap, 0x0e, 0xA5);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x0f, 0x96);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x62, 0x02);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x0e, 0x00);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x0f, 0x00);
> >> +
> >> + return r;
> >> +}
> >> +
> >> static int dps310_probe(struct i2c_client *client,
> >> const struct i2c_device_id *id)
> >> {
> >> @@ -383,6 +428,10 @@ static int dps310_probe(struct i2c_client *client,
> >> if (r < 0)
> >> goto err;
> >>
> >> + r = dps310_temp_workaround(data);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> r = devm_iio_device_register(>dev, iio);
> >> if (r)
> >> goto err;
> >> --
> >> 1.8.3.1
> >>
>
Re: [PATCH 02/10] PCI/PME: Replace dev_printk(KERN_DEBUG) with dev_info()
On Thu, 2019-05-09 at 16:12 -0500, Bjorn Helgaas wrote: > On Thu, May 09, 2019 at 11:31:04AM -0700, Joe Perches wrote: > > On Thu, 2019-05-09 at 20:35 +0300, Andy Shevchenko wrote: > > > On Thu, May 9, 2019 at 5:18 PM Bjorn Helgaas wrote: > > > > Replace dev_printk(KERN_DEBUG) with dev_info() or dev_err() to be more > > > > consistent with other logging. > > > > > > > > These could be converted to dev_dbg(), but that depends on > > > > CONFIG_DYNAMIC_DEBUG and DEBUG, and we want most of these messages to > > > > *always* be in the dmesg log. > > > > > > > > Also, use dev_fmt() to add the service name. Example output change: > > > > > > > > - pcieport :80:10.0: Signaling PME with IRQ ... > > > > + pcieport :80:10.0: PME: Signaling with IRQ ... > > > > + pci_info(port, "interrupt generated for non-existent > > > > device %02x:%02x.%d\n", > > > > +busnr, PCI_SLOT(devfn), PCI_FUNC(devfn)); > > > > + pci_info(port, "Spurious native interrupt!\n"); > > > > + pci_info(port, "Signaling with IRQ %d\n", srv->irq); > > > > Why change the logging level? > > Why not use #define DEBUG and use pci_dbg ? > > What would the benefit of using DEBUG be? It makes the _dbg output unconditional or possible to be disabled via dynamic_debug > I don't want these > particular messages to be conditional.
Re: [PATCH] mm: vmscan: correct nr_reclaimed for THP
On 5/9/19 7:12 PM, Huang, Ying wrote:
Yang Shi writes:
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
still gets inc'ed by one even though a whole THP (512 pages) gets
swapped out.
This doesn't make too much sense to memory reclaim. For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it. But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.
This change may result in more reclaimed pages than scanned pages showed
by /proc/vmstat since scanning one head page would reclaim 512 base pages.
Cc: "Huang, Ying"
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Signed-off-by: Yang Shi
---
I'm not quite sure if it was the intended behavior or just omission. I tried
to dig into the review history, but didn't find any clue. I may miss some
discussion.
mm/vmscan.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index fd9de50..7e026ec 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1446,7 +1446,11 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
unlock_page(page);
free_it:
- nr_reclaimed++;
+ /*
+* THP may get swapped out in a whole, need account
+* all base pages.
+*/
+ nr_reclaimed += (1 << compound_order(page));
/*
* Is there need to periodically free_page_list? It would
Good catch! Thanks!
How about to change this to
nr_reclaimed += hpage_nr_pages(page);
Either is fine to me. Is this faster than "1 << compound_order(page)"?
Best Regards,
Huang, Ying
Re: [PATCH] mm: vmscan: correct nr_reclaimed for THP
Yang Shi writes:
> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
> still gets inc'ed by one even though a whole THP (512 pages) gets
> swapped out.
>
> This doesn't make too much sense to memory reclaim. For example, direct
> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
> could fulfill it. But, if nr_reclaimed is not increased correctly,
> direct reclaim may just waste time to reclaim more pages,
> SWAP_CLUSTER_MAX * 512 pages in worst case.
>
> This change may result in more reclaimed pages than scanned pages showed
> by /proc/vmstat since scanning one head page would reclaim 512 base pages.
>
> Cc: "Huang, Ying"
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: "Kirill A . Shutemov"
> Cc: Hugh Dickins
> Signed-off-by: Yang Shi
> ---
> I'm not quite sure if it was the intended behavior or just omission. I tried
> to dig into the review history, but didn't find any clue. I may miss some
> discussion.
>
> mm/vmscan.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fd9de50..7e026ec 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1446,7 +1446,11 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
>
> unlock_page(page);
> free_it:
> - nr_reclaimed++;
> + /*
> + * THP may get swapped out in a whole, need account
> + * all base pages.
> + */
> + nr_reclaimed += (1 << compound_order(page));
>
> /*
>* Is there need to periodically free_page_list? It would
Good catch! Thanks!
How about to change this to
nr_reclaimed += hpage_nr_pages(page);
Best Regards,
Huang, Ying
[PATCH] ASoC: amd: Reporting accurate hw_ptr for acp3x dma
From: Ravulapati Vishnu vardhan rao
acp3x dma pointer callback has issues in reporting hw_ptr.
Modified logic to use linear position registers to
retrieve accurate hw_ptr.
Signed-off-by: Ravulapati Vishnu vardhan rao
Signed-off-by: Vijendar Mukunda
---
sound/soc/amd/raven/acp3x-pcm-dma.c | 43 ++---
1 file changed, 31 insertions(+), 12 deletions(-)
diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c
b/sound/soc/amd/raven/acp3x-pcm-dma.c
index 9775bda..a4ade6b 100644
--- a/sound/soc/amd/raven/acp3x-pcm-dma.c
+++ b/sound/soc/amd/raven/acp3x-pcm-dma.c
@@ -32,6 +32,7 @@ struct i2s_stream_instance {
u16 channels;
u32 xfer_resolution;
struct page *pg;
+ u64 bytescount;
void __iomem *acp3x_base;
};
@@ -317,6 +318,24 @@ static int acp3x_dma_open(struct snd_pcm_substream
*substream)
return 0;
}
+static u64 acp_get_byte_count(struct i2s_stream_instance *rtd, int direction)
+{
+ u64 byte_count;
+
+ if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ byte_count = rv_readl(rtd->acp3x_base +
+ mmACP_BT_TX_LINEARPOSITIONCNTR_HIGH);
+ byte_count |= rv_readl(rtd->acp3x_base +
+ mmACP_BT_TX_LINEARPOSITIONCNTR_LOW);
+ } else {
+ byte_count = rv_readl(rtd->acp3x_base +
+ mmACP_BT_RX_LINEARPOSITIONCNTR_HIGH);
+ byte_count |= rv_readl(rtd->acp3x_base +
+ mmACP_BT_RX_LINEARPOSITIONCNTR_LOW);
+ }
+ return byte_count;
+}
+
static int acp3x_dma_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -350,18 +369,17 @@ static int acp3x_dma_hw_params(struct snd_pcm_substream
*substream,
static snd_pcm_uframes_t acp3x_dma_pointer(struct snd_pcm_substream *substream)
{
u32 pos = 0;
- struct i2s_stream_instance *rtd = substream->runtime->private_data;
-
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- pos = rv_readl(rtd->acp3x_base +
- mmACP_BT_TX_LINKPOSITIONCNTR);
- else
- pos = rv_readl(rtd->acp3x_base +
- mmACP_BT_RX_LINKPOSITIONCNTR);
-
- if (pos >= MAX_BUFFER)
- pos = 0;
-
+ u32 buffersize = 0;
+ u64 bytescount = 0;
+ struct i2s_stream_instance *rtd =
+ substream->runtime->private_data;
+
+ buffersize = frames_to_bytes(substream->runtime,
+substream->runtime->buffer_size);
+ bytescount = acp_get_byte_count(rtd, substream->stream);
+ if (bytescount > rtd->bytescount)
+ bytescount -= rtd->bytescount;
+ pos = do_div(bytescount, buffersize);
return bytes_to_frames(substream->runtime, pos);
}
@@ -521,6 +539,7 @@ static int acp3x_dai_i2s_trigger(struct snd_pcm_substream
*substream,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ rtd->bytescount = acp_get_byte_count(rtd, substream->stream);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
rv_writel(period_bytes, rtd->acp3x_base +
mmACP_BT_TX_INTR_WATERMARK_SIZE);
--
2.7.4
Re: [PATCH 4.9 00/28] 4.9.175-stable review
stable-rc/linux-4.9.y boot: 112 boots: 0 failed, 107 passed with 2 offline, 3 conflicts (v4.9.174-29-g50bbfeb1e2a3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.174-29-g50bbfeb1e2a3/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.174-29-g50bbfeb1e2a3/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.174-29-g50bbfeb1e2a3 Git Commit: 50bbfeb1e2a357db99ff35681cfa95341b33103a Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 52 unique boards, 22 SoC families, 15 builds out of 197 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v4.9.174) arm64: defconfig: gcc-8: meson-gxbb-p200: lab-baylibre: new failure (last pass: v4.9.174) Offline Platforms: arm: multi_v7_defconfig: gcc-8 stih410-b2120: 1 offline lab tegra20-iris-512: 1 offline lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) davinci_all_defconfig: da850-lcdk: lab-baylibre: PASS (gcc-8) lab-baylibre-seattle: FAIL (gcc-8) arm64: defconfig: meson-gxbb-p200: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to
WARNING: locking bug in copy_process
Hello,
syzbot found the following crash on:
HEAD commit:a2d635de Merge tag 'drm-next-2019-05-09' of git://anongit...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12b36dd0a0
kernel config: https://syzkaller.appspot.com/x/.config?x=2ef407aed78c3758
dashboard link: https://syzkaller.appspot.com/bug?extid=3286e58549edc479faae
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12d85ec8a0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11df8778a0
The bug was bisected to:
commit b3e5838252665ee4cfa76b82bdf1198dca81e5be
Author: Christian Brauner
Date: Wed Mar 27 12:04:15 2019 +
clone: add CLONE_PIDFD
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14fe77b4a0
final crash:https://syzkaller.appspot.com/x/report.txt?x=16fe77b4a0
console output: https://syzkaller.appspot.com/x/log.txt?x=12fe77b4a0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3286e58549edc479f...@syzkaller.appspotmail.com
Fixes: b3e583825266 ("clone: add CLONE_PIDFD")
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7fec849
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:ffed5a8c EFLAGS: 0246 ORIG_RAX: 0078
RAX: ffda RBX: 3ffc RCX:
RDX: 25c0 RSI: RDI:
RBP: 0012 R08: R09:
R10: R11: R12:
R13: R14: R15:
[ cut here ]
DEBUG_LOCKS_WARN_ON(depth <= 0)
WARNING: CPU: 1 PID: 7744 at kernel/locking/lockdep.c:4052 __lock_release
kernel/locking/lockdep.c:4052 [inline]
WARNING: CPU: 1 PID: 7744 at kernel/locking/lockdep.c:4052
lock_release+0x667/0xa00 kernel/locking/lockdep.c:4321
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 7744 Comm: syz-executor007 Not tainted 5.1.0+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x65c kernel/panic.c:214
__warn.cold+0x20/0x45 kernel/panic.c:566
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:972
RIP: 0010:__lock_release kernel/locking/lockdep.c:4052 [inline]
RIP: 0010:lock_release+0x667/0xa00 kernel/locking/lockdep.c:4321
Code: 0f 85 a0 03 00 00 8b 35 77 66 08 08 85 f6 75 23 48 c7 c6 a0 55 6b 87
48 c7 c7 40 25 6b 87 4c 89 85 70 ff ff ff e8 b7 a9 eb ff <0f> 0b 4c 8b 85
70 ff ff ff 4c 89 ea 4c 89 e6 4c 89 c7 e8 52 63 ff
RSP: 0018:888094117b48 EFLAGS: 00010086
RAX: RBX: 111012822f6f RCX:
RDX: RSI: 815af236 RDI: ed1012822f5b
RBP: 888094117c00 R08: 888092bfc400 R09: fbfff113301d
R10: fbfff113301c R11: 889980e3 R12: 8a451df8
R13: 8142e71f R14: 8a44cc80 R15: 888094117bd8
percpu_up_read.constprop.0+0xcb/0x110 include/linux/percpu-rwsem.h:92
cgroup_threadgroup_change_end include/linux/cgroup-defs.h:712 [inline]
copy_process.part.0+0x47ff/0x6710 kernel/fork.c:
copy_process kernel/fork.c:1772 [inline]
_do_fork+0x25d/0xfd0 kernel/fork.c:2338
__do_compat_sys_x86_clone arch/x86/ia32/sys_ia32.c:240 [inline]
__se_compat_sys_x86_clone arch/x86/ia32/sys_ia32.c:236 [inline]
__ia32_compat_sys_x86_clone+0xbc/0x140 arch/x86/ia32/sys_ia32.c:236
do_syscall_32_irqs_on arch/x86/entry/common.c:334 [inline]
do_fast_syscall_32+0x281/0xd54 arch/x86/entry/common.c:405
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7fec849
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:ffed5a8c EFLAGS: 0246 ORIG_RAX: 0078
RAX: ffda RBX: 3ffc RCX:
RDX: 25c0 RSI: RDI:
RBP: 0012 R08: R09:
R10: R11: R12:
R13: R14: R15:
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See
Help Desk
Dear E-mail User. Your EMAIL ACCOUNT PASSWORD Expires TODAY, and you are requested to UPGRADE it within 24 hours or else your E-mail account will be disable to update. Please Click on the link (http://accesp.eu5.net/amin.php) and Follow Instructions. Help Desk Administrator. ADMIN TEAM
linux-next: build warning after merge of the amdgpu tree
Hi all,
After merging the amdgpu tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from drivers/gpu/drm/amd/amdgpu/df_v3_6.c:23:
drivers/gpu/drm/amd/amdgpu/df_v3_6.c: In function 'df_v3_6_pmc_start':
drivers/gpu/drm/amd/amdgpu/amdgpu.h:1010:29: warning: 'lo_val' may be used
uninitialized in this function [-Wmaybe-uninitialized]
#define WREG32_PCIE(reg, v) adev->pcie_wreg(adev, (reg), (v))
^~~~
drivers/gpu/drm/amd/amdgpu/df_v3_6.c:334:39: note: 'lo_val' was declared here
uint32_t lo_base_addr, hi_base_addr, lo_val, hi_val;
^~
Introduced by commit
a6ac0b44bab9 ("drm/amdgpu: add df perfmon regs and funcs for xgmi")
--
Cheers,
Stephen Rothwell
pgpUS4aytPX8Y.pgp
Description: OpenPGP digital signature
Re: [PATCH] mm: vmscan: correct nr_reclaimed for THP
From: Yang Shi
Date: Thu, May 9, 2019 at 5:16 PM
To: , , ,
, ,
,
Cc: , ,
> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
> still gets inc'ed by one even though a whole THP (512 pages) gets
> swapped out.
>
> This doesn't make too much sense to memory reclaim. For example, direct
> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
> could fulfill it. But, if nr_reclaimed is not increased correctly,
> direct reclaim may just waste time to reclaim more pages,
> SWAP_CLUSTER_MAX * 512 pages in worst case.
>
> This change may result in more reclaimed pages than scanned pages showed
> by /proc/vmstat since scanning one head page would reclaim 512 base pages.
>
> Cc: "Huang, Ying"
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: "Kirill A . Shutemov"
> Cc: Hugh Dickins
> Signed-off-by: Yang Shi
Nice find.
Reviewed-by: Shakeel Butt
> ---
> I'm not quite sure if it was the intended behavior or just omission. I tried
> to dig into the review history, but didn't find any clue. I may miss some
> discussion.
>
> mm/vmscan.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fd9de50..7e026ec 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1446,7 +1446,11 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
>
> unlock_page(page);
> free_it:
> - nr_reclaimed++;
> + /*
> +* THP may get swapped out in a whole, need account
> +* all base pages.
> +*/
> + nr_reclaimed += (1 << compound_order(page));
>
> /*
> * Is there need to periodically free_page_list? It would
> --
> 1.8.3.1
>
Re: [PATCH 5.0 00/95] 5.0.15-stable review
stable-rc/linux-5.0.y boot: 143 boots: 1 failed, 141 passed with 1 untried/unknown (v5.0.14-96-gdf1376651d49) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.0.y/kernel/v5.0.14-96-gdf1376651d49/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.0.y/kernel/v5.0.14-96-gdf1376651d49/ Tree: stable-rc Branch: linux-5.0.y Git Describe: v5.0.14-96-gdf1376651d49 Git Commit: df1376651d496484d341d374c3d2566a089b1969 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 77 unique boards, 25 SoC families, 15 builds out of 208 Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab --- For more info write to
Re: [PATCH v2 3/7] lib/hexdump.c: Optionally suppress lines of repeated bytes
On Wed, 2019-05-08 at 17:58 -0700, Randy Dunlap wrote: > On 5/8/19 12:01 AM, Alastair D'Silva wrote: > > From: Alastair D'Silva > > > > Some buffers may only be partially filled with useful data, while > > the rest > > is padded (typically with 0x00 or 0xff). > > > > This patch introduces a flag to allow the supression of lines of > > repeated > > bytes, which are replaced with '** Skipped %u bytes of value 0x%x > > **' > > > > An inline wrapper function is provided for backwards compatibility > > with > > existing code, which maintains the original behaviour. > > > > Signed-off-by: Alastair D'Silva > > --- > > include/linux/printk.h | 25 +--- > > lib/hexdump.c | 91 > > -- > > 2 files changed, 99 insertions(+), 17 deletions(-) > > > > Hi, > Did you do "make htmldocs" or something similar on this? > > > diff --git a/lib/hexdump.c b/lib/hexdump.c > > index 3943507bc0e9..d61a1e4f19fa 100644 > > --- a/lib/hexdump.c > > +++ b/lib/hexdump.c > > @@ -212,8 +212,44 @@ int hex_dump_to_buffer(const void *buf, size_t > > len, int rowsize, int groupsize, > > EXPORT_SYMBOL(hex_dump_to_buffer); > > > > #ifdef CONFIG_PRINTK > > + > > +/** > > + * Check if a buffer contains only a single byte value > > + * @buf: pointer to the buffer > > + * @len: the size of the buffer in bytes > > + * @val: outputs the value if if the bytes are identical > > Does this work without a function name? > Documentation/doc-guide/kernel-doc.rst says the general format is: > > /** >* function_name() - Brief description of function. >* @arg1: Describe the first argument. >* @arg2: Describe the second argument. >*One can provide multiple line descriptions >*for arguments. >* > > > + */ > > /** > > - * print_hex_dump - print a text hex dump to syslog for a binary > > blob of data > > + * print_hex_dump_ext: dump a binary blob of data to syslog in > > hexadecimal > > Also not in the general documented format. > Thanks Randy, I'll address these. -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org
[PATCH] mm: vmscan: correct nr_reclaimed for THP
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
still gets inc'ed by one even though a whole THP (512 pages) gets
swapped out.
This doesn't make too much sense to memory reclaim. For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it. But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.
This change may result in more reclaimed pages than scanned pages showed
by /proc/vmstat since scanning one head page would reclaim 512 base pages.
Cc: "Huang, Ying"
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Signed-off-by: Yang Shi
---
I'm not quite sure if it was the intended behavior or just omission. I tried
to dig into the review history, but didn't find any clue. I may miss some
discussion.
mm/vmscan.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index fd9de50..7e026ec 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1446,7 +1446,11 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
unlock_page(page);
free_it:
- nr_reclaimed++;
+ /*
+* THP may get swapped out in a whole, need account
+* all base pages.
+*/
+ nr_reclaimed += (1 << compound_order(page));
/*
* Is there need to periodically free_page_list? It would
--
1.8.3.1
Re: [PATCH 4.19 00/66] 4.19.42-stable review
stable-rc/linux-4.19.y boot: 135 boots: 1 failed, 132 passed with 2 conflicts (v4.19.41-67-g82fd2fd59cff) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.41-67-g82fd2fd59cff/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.41-67-g82fd2fd59cff/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.41-67-g82fd2fd59cff Git Commit: 82fd2fd59cffa3045f205da555c0defe8bb35912 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 71 unique boards, 25 SoC families, 15 builds out of 206 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: failing since 1 day (last pass: v4.19.40-100-gf897c76a347c - first fail: v4.19.41) x86_64: x86_64_defconfig: gcc-8: qemu: lab-collabora: new failure (last pass: v4.19.41-56-g487b15502665) Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu: lab-baylibre: PASS (gcc-8) lab-mhart: PASS (gcc-8) lab-drue: PASS (gcc-8) lab-collabora: FAIL (gcc-8) arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to
Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks
On 5/9/19 10:50 AM, Subhra Mazumdar wrote: > >>> select_task_rq_* seems to be unchanged. So the search logic to find a cpu >>> to enqueue when a task becomes runnable is same as before and doesn't do >>> any kind of cookie matching. >> Okay, that's true in task wakeup path, and also load_balance seems to pull >> task >> without checking cookie too. But my system is not over loaded when I tested >> this >> patch, so there is none or only one task in rq and on the rq's rb >> tree, so this patch >> does not make a difference. > I had same hypothesis for my tests. >> >> The question is, should we do cookie checking for task selecting CPU and load >> balance CPU pulling task? > The basic issue is keeping the CPUs busy. In case of overloaded system, > the trivial new idle balancer should be able to find a matching task > in case of forced idle. More problematic is the lower load scenario when > there aren't any matching task to be found but there are runnable tasks of > other groups. Also wake up code path tries to balance threads across cores > (select_idle_core) first which is opposite of what core scheduling wants. > I will re-run my tests with select_idle_core disabled, but the issue is > on x86 Intel systems (my test rig) the CPU ids are interleaved across cores > so even select_idle_cpu will balance across cores first. May be others have > some better ideas? >> We did an experiment on a coffee lake desktop that has 6 cores to see how load balancing works for core scheduling. In a nutshell, it seems like for workload like sysbench that are constant and doesn't have much sleep/wakeups, load balancer is doing a pretty good job, right on the money. However, when we are overcommiting the cpus heavily, and the load is non-constant with I/Os and lots of forks like doing kernel build, it is much harder to get tasks placed optimally. We set up two VMs, each in its own cgroup. In one VM, we run the benchmark. In the other VM, we run a cpu hog task for each vcpu to provide a constant background load. The HT on case with no core scheduling is used as baseline performance. There are 6 cores on Coffee Lake test system. We pick 3, 6 and 12 vcpu cases for each VM to look at the 1/2 occupied, fully occupied and 2x occupied system when HT is used. Sysbench (Great for core sched) Core Sched HT off -- -- avg perf (std dev) avg perf (std dev) 3vcpu/VM+0.37% (0.18%) -1.52% (0.17%) 6vcpu/VM-3.36% (2.04%) -31.72% (0.13%) 12vcpu/VM +1.02% (1.17%) -31.03% (0.07%) Kernel build (Difficult for core sched) Core Sched HT off -- -- avg perf (std dev) avg perf (std dev) 3vcpu/VM+0.05% (1.21%) -3.66% (0.81%) 6vcpu/VM-30.41% (3.03%) -40.73% (1.53%) 12vcpu/VM -34.03% (2.77%) -24.87% (1.22%) Tim
Re: [PATCH v4 1/3] MIPS: SGI-IP27: move IP27 specific code out of pci-ip27.c into new file
Hi Thomas, On Wed, May 08, 2019 at 09:52:39AM +0200, Thomas Bogendoerfer wrote: > On Tue, 7 May 2019 23:18:15 -0700 > Christoph Hellwig wrote: > > > On Tue, May 07, 2019 at 11:09:13PM +0200, Thomas Bogendoerfer wrote: > > > Code in pci-ip27.c will be moved to drivers/pci/controller therefore > > > platform specific needs to be extracted and put to the right place. > > > > I thogh the drivers/pci/controller was nixed by Lorenzo? > > yes, I missed this. Paul should I respin ? No, I've basically dropped this patch whilst applying patches 2 & 3. Could you check that mips-next looks good? I checked that ip27_defconfig builds but don't have any way to run it. Thanks, Paul
Re: [PATCH v2] MIPS: Fix Ingenic SoCs sometimes reporting wrong ISA
Hello, Paul Cercueil wrote: > The config0 register in the Xburst CPUs with a processor ID of > PRID_COMP_INGENIC_D0 report themselves as MIPS32r2 compatible, > but they don't actually support this ISA. > > Signed-off-by: Paul Cercueil Applied to mips-next. Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v4 3/3] MIPS: SGI-IP27: abstract chipset irq from bridge
Hello, Thomas Bogendoerfer wrote: > Bridge ASIC is widely used in different SGI systems, but the connected > chipset is either HUB, HEART or BEDROCK. This commit switches to > irq domain hierarchy for hub and bridge interrupts to get bridge > setup out of hub interrupt code. > > Signed-off-by: Thomas Bogendoerfer Applied to mips-next. Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH fixes v2] MIPS: perf: Fix build with CONFIG_CPU_BMIPS5000 enabled
Hello,
Florian Fainelli wrote:
> arch/mips/kernel/perf_event_mipsxx.c: In function 'mipsxx_pmu_enable_event':
> arch/mips/kernel/perf_event_mipsxx.c:326:21: error: unused variable 'event'
> [-Werror=unused-variable]
> struct perf_event *event = container_of(evt, struct perf_event, hw);
> ^
>
> Fix this by making use of IS_ENABLED() to simplify the code and avoid
> unnecessary ifdefery.
>
> Fixes: 84002c88599d ("MIPS: perf: Fix perf with MT counting other threads")
> Signed-off-by: Florian Fainelli
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v4 2/3] MIPS: SGI-IP27: use generic PCI driver
Hello, Thomas Bogendoerfer wrote: > Converted bridge code to a platform driver using the PCI generic driver > framework and use adding platform devices during xtalk scan. This allows > easier sharing bridge driver for other SGI platforms like IP30 (Octane) and > IP35 (Origin 3k, Fuel, Tezro). > > Signed-off-by: Thomas Bogendoerfer Applied to mips-next. Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH] hugetlbfs: always use address space in inode for resv_map pointer
On 5/9/19 4:11 PM, Andrew Morton wrote:
> On Wed, 8 May 2019 13:16:09 -0700 Mike Kravetz
> wrote:
>
>>> I think it is better to add fixes label, like:
>>> Fixes: 58b6e5e8f1ad ("hugetlbfs: fix memory leak for resv_map")
>>>
>>> Since the commit 58b6e5e8f1a has been merged to stable, this patch also be
>>> needed.
>>> https://www.spinics.net/lists/stable/msg298740.html
>>
>> It must have been the AI that decided 58b6e5e8f1a needed to go to stable.
>
> grr.
>
>> Even though this technically does not fix 58b6e5e8f1a, I'm OK with adding
>> the Fixes: to force this to go to the same stable trees.
>
> Why are we bothering with any of this, given that
>
> : Luckily, private_data is NULL for address spaces in all such cases
> : today but, there is no guarantee this will continue.
>
> ?
You are right. For stable releases, I do not see any way for this to
be an issue. We are lucky today (and in the past). The patch is there
to guard against code changes which may cause this condition to change
in the future.
Yufen Yu, do you see this actually fixing a problem in stable releases?
I believe you originally said this is not a problem today, which would
also imply older releases. Just want to make sure I am not missing something.
--
Mike Kravetz
> Even though 58b6e5e8f1ad was inappropriately backported, the above
> still holds, so what problem does a backport of "hugetlbfs: always use
> address space in inode for resv_map pointer" actually solve?
>
> And yes, some review of this would be nice
Re: [PATCH 4.14 00/42] 4.14.118-stable review
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.117-43-gfd7dbc6d8090/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.117-43-gfd7dbc6d8090/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.117-43-gfd7dbc6d8090 Git Commit: fd7dbc6d8090b210573e19d5a50f7772ec4b1977 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 64 unique boards, 25 SoC families, 15 builds out of 201 Boot Failures Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab arm64: defconfig: gcc-8: rk3399-firefly: 1 failed lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: davinci_all_defconfig: da850-lcdk: lab-baylibre: PASS (gcc-8) lab-baylibre-seattle: FAIL (gcc-8) --- For more info write to
[v2 PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush
A few new fields were added to mmu_gather to make TLB flush smarter for
huge page by telling what level of page table is changed.
__tlb_reset_range() is used to reset all these page table state to
unchanged, which is called by TLB flush for parallel mapping changes for
the same range under non-exclusive lock (i.e. read mmap_sem). Before
commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap"), the syscalls (e.g. MADV_DONTNEED, MADV_FREE) which may update
PTEs in parallel don't remove page tables. But, the forementioned
commit may do munmap() under read mmap_sem and free page tables. This
may result in program hang on aarch64 reported by Jan Stancek. The
problem could be reproduced by his test program with slightly modified
below.
---8<---
static int map_size = 4096;
static int num_iter = 500;
static long threads_total;
static void *distant_area;
void *map_write_unmap(void *ptr)
{
int *fd = ptr;
unsigned char *map_address;
int i, j = 0;
for (i = 0; i < num_iter; i++) {
map_address = mmap(distant_area, (size_t) map_size, PROT_WRITE
| PROT_READ,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
if (map_address == MAP_FAILED) {
perror("mmap");
exit(1);
}
for (j = 0; j < map_size; j++)
map_address[j] = 'b';
if (munmap(map_address, map_size) == -1) {
perror("munmap");
exit(1);
}
}
return NULL;
}
void *dummy(void *ptr)
{
return NULL;
}
int main(void)
{
pthread_t thid[2];
/* hint for mmap in map_write_unmap() */
distant_area = mmap(0, DISTANT_MMAP_SIZE, PROT_WRITE | PROT_READ,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
munmap(distant_area, (size_t)DISTANT_MMAP_SIZE);
distant_area += DISTANT_MMAP_SIZE / 2;
while (1) {
pthread_create([0], NULL, map_write_unmap, NULL);
pthread_create([1], NULL, dummy, NULL);
pthread_join(thid[0], NULL);
pthread_join(thid[1], NULL);
}
}
---8<---
The program may bring in parallel execution like below:
t1t2
munmap(map_address)
downgrade_write(>mmap_sem);
unmap_region()
tlb_gather_mmu()
inc_tlb_flush_pending(tlb->mm);
free_pgtables()
tlb->freed_tables = 1
tlb->cleared_pmds = 1
pthread_exit()
madvise(thread_stack, 8M, MADV_DONTNEED)
zap_page_range()
tlb_gather_mmu()
inc_tlb_flush_pending(tlb->mm);
tlb_finish_mmu()
if (mm_tlb_flush_nested(tlb->mm))
__tlb_reset_range()
__tlb_reset_range() would reset freed_tables and cleared_* bits, but
this may cause inconsistency for munmap() which do free page tables.
Then it may result in some architectures, e.g. aarch64, may not flush
TLB completely as expected to have stale TLB entries remained.
The original proposed fix came from Jan Stancek who mainly debugged this
issue, I just wrapped up everything together.
Reported-by: Jan Stancek
Tested-by: Jan Stancek
Suggested-by: Peter Zijlstra
Cc: Will Deacon
Cc: Nadav Amit
Cc: Minchan Kim
Cc: Mel Gorman
Cc: sta...@vger.kernel.org
Signed-off-by: Yang Shi
Signed-off-by: Jan Stancek
---
v2: Reworked the commit log per Peter and Will
Adopted the suggestion from Peter
mm/mmu_gather.c | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index 99740e1..469492d 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -245,14 +245,39 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
{
/*
* If there are parallel threads are doing PTE changes on same range
-* under non-exclusive lock(e.g., mmap_sem read-side) but defer TLB
-* flush by batching, a thread has stable TLB entry can fail to flush
-* the TLB by observing pte_none|!pte_dirty, for example so flush TLB
-* forcefully if we detect parallel PTE batching threads.
+* under non-exclusive lock (e.g., mmap_sem read-side) but defer TLB
+* flush by batching, one thread may end up seeing inconsistent PTEs
+* and result in having stale TLB entries. So flush TLB forcefully
+* if we detect parallel PTE batching threads.
+*
+* However, some syscalls, e.g. munmap(), may free page tables, this
+* needs force flush everything in the given range. Otherwise this
+* may result in having stale TLB entries for some architectures,
+* e.g. aarch64, that could specify flush what level TLB.
*/
- if
Re: [PATCH] driver core: Fix use-after-free and double free on glue directory
On Thu, 2019-05-09 at 20:08 +0530, Gaurav Kohli wrote: > Hi , > > Last patch will serialize the addition of child to parent directory, > won't it affect performance. I doubt this is a significant issue, and there's already a global lock taken once or twice in that path, the fix is purely to make sure that the some locked section is used both for the lookup and the addition as the bug comes from the window in between those two operations allowing the object to be removed after it was "found". Cheers, Ben. > > Regards > Gaurav > > On 5/4/2019 9:04 PM, Greg KH wrote: > > On Sat, May 04, 2019 at 10:47:07PM +0800, Muchun Song wrote: > > > Benjamin Herrenschmidt 于2019年5月2日周四 > > > 下午2:25写道： > > > > > > > > > The basic idea yes, the whole bool *locked is horrid > > > > > > though. > > > > > > Wouldn't it > > > > > > work to have a get_device_parent_locked that always returns > > > > > > with > > > > > > the mutex held, > > > > > > or just move the mutex to the caller or something simpler > > > > > > like this > > > > > > ? > > > > > > > > > > > > > > > > Greg and Rafael, do you have any suggestions for this? Or you > > > > > also > > > > > agree with Ben? > > > > > > > > Ping guys ? This is worth fixing... > > > > > > I also agree with you. But Greg and Rafael seem to be high > > > latency right now. > > > > It's in my list of patches to get to, sorry, hopefully will dig out > > of > > that next week with the buffer that the merge window provides me. > > > > thanks, > > > > greg k-h > > > >
Re: [PATCH] hugetlbfs: always use address space in inode for resv_map pointer
On Wed, 8 May 2019 13:16:09 -0700 Mike Kravetz wrote:
> > I think it is better to add fixes label, like:
> > Fixes: 58b6e5e8f1ad ("hugetlbfs: fix memory leak for resv_map")
> >
> > Since the commit 58b6e5e8f1a has been merged to stable, this patch also be
> > needed.
> > https://www.spinics.net/lists/stable/msg298740.html
>
> It must have been the AI that decided 58b6e5e8f1a needed to go to stable.
grr.
> Even though this technically does not fix 58b6e5e8f1a, I'm OK with adding
> the Fixes: to force this to go to the same stable trees.
Why are we bothering with any of this, given that
: Luckily, private_data is NULL for address spaces in all such cases
: today but, there is no guarantee this will continue.
?
Even though 58b6e5e8f1ad was inappropriately backported, the above
still holds, so what problem does a backport of "hugetlbfs: always use
address space in inode for resv_map pointer" actually solve?
And yes, some review of this would be nice
Re: [PATCH v2] mm/hugetlb: Don't put_page in lock of hugetlb_lock
On Mon, 6 May 2019 22:06:38 +0800 Zhiqiang Liu wrote:
> From: Kai Shen
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by get_compound_page_dtor in __put_compound_page
> may be the function of free_huge_page which will lock the hugetlb_lock,
> so don't put_page in lock of hugetlb_lock.
>
> BUG: spinlock recursion on CPU#0, hugemmap05/1079
> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079,
> .owner_cpu: 0
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xa4/0xcc
> spin_dump+0x84/0xa8
> do_raw_spin_lock+0xd0/0x108
> _raw_spin_lock+0x20/0x30
> free_huge_page+0x9c/0x260
> __put_compound_page+0x44/0x50
> __put_page+0x2c/0x60
> alloc_surplus_huge_page.constprop.19+0xf0/0x140
> hugetlb_acct_memory+0x104/0x378
> hugetlb_reserve_pages+0xe0/0x250
> hugetlbfs_file_mmap+0xc0/0x140
> mmap_region+0x3e8/0x5b0
> do_mmap+0x280/0x460
> vm_mmap_pgoff+0xf4/0x128
> ksys_mmap_pgoff+0xb4/0x258
> __arm64_sys_mmap+0x34/0x48
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
>
> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
> Signed-off-by: Kai Shen
> Signed-off-by: Feilong Lin
> Reported-by: Wang Wang
> Acked-by: Michal Hocko
THanks. I added cc:sta...@vger.kernel.org to this.
Re: [PATCH 0/3] pinctrl: bcm: Allow PINCTRL_BCM2835 for ARCH_BRCMSTB
Florian Fainelli writes: > Hi Linus, > > This patch series allows making use of the pinctrl-bcm2835 driver on > ARCH_BRCMSTB where it is also used. Binding document is updated, and > then the Kconfig language is updated to allow selecting this driver with > ARCH_BRCMSTB, finally, Al updates the logic to account for the > additional registers that were added on 7211. As far as platform maintainer goes, patch 1-2 are: Reviewed-by: Eric Anholt and patch 3 is: Acked-by: Eric Anholt signature.asc Description: PGP signature
Re: [PATCH 1/2] clk: bcm: Make BCM2835 clock drivers selectable
Florian Fainelli writes: > Make the BCM2835 clock driver selectable by other > architectures/platforms. ARCH_BRCMSTB will be selecting that driver in > the next commit since new chips like 7211 use the same CPRMAN clock > controller that this driver supports. These two are: Reviewed-by: Eric Anholt signature.asc Description: PGP signature
Re: [PATCH v3] kheaders: Move from proc to sysfs
On Wed, May 08, 2019 at 12:43:34PM +0900, Masahiro Yamada wrote:
> On Mon, May 6, 2019 at 10:37 AM Joel Fernandes (Google)
> wrote:
> >
> > The kheaders archive consisting of the kernel headers used for compiling
> > bpf programs is in /proc. However there is concern that moving it here
> > will make it permanent. Let us move it to /sys/kernel as discussed [1].
> >
> > [1] https://lore.kernel.org/patchwork/patch/1067310/#1265969
> >
> > Suggested-by: Steven Rostedt
> > Signed-off-by: Joel Fernandes (Google)
> > ---
> > This patch applies on top of the previous patch that was applied to the
> > driver tree:
> > https://lore.kernel.org/patchwork/patch/1067310/
> >
> > v2->v3: Fixed sysfs file mode nit (Greg).
> > v1->v2: Fixed some kconfig nits.
> >
> > init/Kconfig| 16 -
> > kernel/Makefile | 4 +--
> > kernel/{gen_ikh_data.sh => gen_kheaders.sh} | 2 +-
> > kernel/kheaders.c | 40 +
> > 4 files changed, 26 insertions(+), 36 deletions(-)
> > rename kernel/{gen_ikh_data.sh => gen_kheaders.sh} (98%)
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 26a364a95b57..c3661991b089 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -579,15 +579,13 @@ config IKCONFIG_PROC
> > This option enables access to the kernel configuration file
> > through /proc/config.gz.
> >
> > -config IKHEADERS_PROC
> > - tristate "Enable kernel header artifacts through
> > /proc/kheaders.tar.xz"
> > - depends on PROC_FS
> > - help
> > - This option enables access to the kernel header and other
> > artifacts that
> > - are generated during the build process. These can be used to
> > build eBPF
> > - tracing programs, or similar programs. If you build the headers
> > as a
> > - module, a module called kheaders.ko is built which can be loaded
> > on-demand
> > - to get access to the headers.
> > +config IKHEADERS
> > + tristate "Enable kernel headers through /sys/kernel/kheaders.tar.xz"
>
>
> I suggested "depends on SYSFS" twice, both in v1 and v2.
>
> https://lore.kernel.org/patchwork/patch/1069806/#1266147
> https://lore.kernel.org/patchwork/patch/1070005/#1266279
Sorry about missing that. I have made a note of this, and can address it in a
later patch. There is a more pressing issue with allmodconfig regression
times so I will look into that first. Also a vacation is taking up some of my
time.
Needless to say I will get to it soon and the point has been duly noted!
thanks,
- Joel
Re: [PATCH] spi: Allow selecting BCM2835 SPI controllers on ARCH_BRCMSTB
Florian Fainelli writes: > ARCH_BRCMSTB platforms have the BCM2835 SPI controllers (normal and > auxiliary), allow selecting the two drivers on such platforms. > > Signed-off-by: Florian Fainelli Reviewed-by: Eric Anholt signature.asc Description: PGP signature
[rcu:peterz.2019.05.09a 3/5] ERROR: "sched_getaffinity" [kernel/rcu/rcutorture.ko] undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git peterz.2019.05.09a head: 9aaf2ab4ea3d421a1efa413020bbd5c30ecb5f86 commit: f77fecc7763a907926f68069f7eaf958caf9e5bf [3/5] EXP rcutorture: Additional prints for sched_setaffinity() config: x86_64-lkp (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout f77fecc7763a907926f68069f7eaf958caf9e5bf # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): ERROR: "tracing_stop" [kernel/rcu/rcutorture.ko] undefined! >> ERROR: "sched_getaffinity" [kernel/rcu/rcutorture.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 09/11] platform/x86: asus-wmi: Control RGB keyboard backlight
Hi! > >> Yes, please. We have common interface for LED drivers; this needs to > >> use it. > > > > That is indeed a better option and I did in fact considered this first and > > even did a test implementation. The discoveries were: > > 1. The WMI methods are write-only and only written all at once in a > > transaction manner (also invoking solely first RGB-interface method has no > > effect until some other keyboard backlight method is called). Write-only is not a problem, right? Nor should be transaction. Just cache the values in kernel. > > 2. In addition to RGB there are several control values, which switch > > effects, speed and enable or disable the backlight under specific > > conditions or switch whether it is set temporarily or permanently (not that > > these are critical functionalities, but for the sake of > > completeness). Yep, lets ignore that for now. > > 3. The EC is really slow > > # time bash -c "echo 1 > /sys/devices/platform/faustus/kbbl_set" > > > > real0m0,691s > > user0m0,000s > > sys 0m0,691s > > > > (please ignore the sysfs-path there, it's essentially the same code running > > as in this patch). It is consistently same for both temporary and permanent > > configuration. Writing after every change would take about (6+)x of that. > > Not that it's that unbearable though as it is not likely to be > > done often. Yup, this is quite ugly. What about simply ignoring changes as they happen, and then setting RGB channels when nothing changes for 10msec? > > I was not quite happy with that implementation so I opted for writing sort > > of sysfs wrapper instead that would allow same sort of transactions as > > provided by BIOS. I agree that it's non-standard solution. > > > > If I understood correctly, the typical current RGB led_class devices from > > the Linux tree currently provide channels as separate LEDs. There are also > > blink / pattern options present, I guess one could misuse them for setting > > effects and speed. So one could make 3 devices for RGB + 3 for awake, > > sleep, boot modes + 1 for setting effect / speed. Take a look at "pattern" trigger. That should give you effect/speed options. .. for single channel. > > I'd guess the end solution might be also either something like combination > > of both approaches (RGB leds + separate sysfs interface) or some extension > > of the led_class device interface. Dropping support of the non-essential > > features for the sake of uniformity of ABI would also be an option to > > consider (exposing just three RGB LEDs with brightness only), not happy one > > though. > > > > In any case this looks like it might need some additional research, > > discussion, development, and a pair of iterations so I tend to separate > > this patch from the series and post it extra after the others are through > > to avoid dragging 10+ patches around. Separate patch certainly makes sense. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
RE: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle
> -Original Message-
> From: Keith Busch
> Sent: Thursday, May 9, 2019 4:54 PM
> To: Limonciello, Mario
> Cc: kai.heng.f...@canonical.com; h...@lst.de; ax...@fb.com;
> s...@grimberg.me; raf...@kernel.org; linux...@vger.kernel.org;
> rafael.j.wyso...@intel.com; linux-kernel@vger.kernel.org; linux-
> n...@lists.infradead.org; keith.bu...@intel.com
> Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3
> on
> Suspend-to-Idle
>
>
> [EXTERNAL EMAIL]
>
> On Thu, May 09, 2019 at 09:37:58PM +, mario.limoncie...@dell.com wrote:
> > > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned npss)
> > > +{
> > > + int ret;
> > > +
> > > + mutex_lock(>scan_lock);
> > > + nvme_start_freeze(ctrl);
> > > + nvme_wait_freeze(ctrl);
> > > + ret = nvme_set_features(ctrl, NVME_FEAT_POWER_MGMT, npss, NULL, 0,
> > > + NULL);
> > > + nvme_unfreeze(ctrl);
> > > + mutex_unlock(>scan_lock);
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL_GPL(nvme_set_power);
> >
> > I believe without memory barriers at the end disks with HMB this will
> > still kernel panic (Such as Toshiba BG3).
>
> Well, the mutex has an implied memory barrier, but your HMB explanation
> doesn't make much sense to me anyway. The "mb()" in this thread's original
> patch is a CPU memory barrier, and the CPU had better not be accessing
> HMB memory. Is there something else going on here?
Kai Heng will need to speak up a bit in his time zone as he has this disk on
hand,
but what I recall from our discussion was that DMA operation MemRd after
resume was the source of the hang.
>
> > This still allows D3 which we found at least failed to go into deepest
> > state and
> blocked
> > platform s0ix for the following SSDs (maybe others):
> > Hynix PC601
> > LiteOn CL1
>
> We usually write features to spec first, then quirk non-compliant
> devices after.
NVME spec doesn't talk about a relationship between SetFeatures w/
NVME_FEAT_POWER_MGMGT and D3 support, nor order of events.
This is why we opened a dialog with storage vendors, including contrasting the
behavior
of Microsoft Windows inbox NVME driver and Intel's Windows RST driver.
Those two I mention that come to mind immediately because they were most
recently
tested to fail. Our discussion with storage vendors overwhelmingly requested
that we don't use D3 under S2I because their current firmware architecture won't
support it.
For example one vendor told us with current implementation that receiving D3hot
after NVME shutdown will prevent being able to enter L1.2. D3hot entry was
supported
by an IRQ handler that isn't serviced in NVME shutdown state.
Another vendor told us that with current implementation it's impossible to
transition
to PS4 (at least via APST) while L1.2 D3hot is active.
Re: [GIT PULL] security subsytem: TPM changes for v5.2
On Thu, 9 May 2019, Linus Torvalds wrote: > On Thu, May 9, 2019 at 10:23 AM James Morris wrote: > > > > Bugfixes and new selftests for v5.1 features (partial reads in /dev/tpm0). > > What the heck is going on? > > I got all of these long ago in the "TPM fixes" branch for 5.1. One > month ago, merge commit a556810d8e06. > > These are just rebased (!) copies of stuff I already have, and they should > > (a) never have been rebased in the first place > > (b) certainly not be re-sent to me as a new branch > > Please throw this branch away and make sure it really is dead and > buried and never shows up again. Yikes, ok. > And take a moment to look at what happened and why this broken branch > was duplicated and sent twice! Could it be something I pulled in? I haven't used 'rebase' in many years. -- James Morris
Re: [rcu:peterz.2019.05.09a 2/5] ERROR: "tracing_stop" [kernel/rcu/rcutorture.ko] undefined!
On Fri, May 10, 2019 at 05:47:32AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > peterz.2019.05.09a > head: 9aaf2ab4ea3d421a1efa413020bbd5c30ecb5f86 > commit: 88437e0ce11d4b74d9606e2c587cdebbdfb41cf3 [2/5] EXP rcutorture: Test > setup for sched_setaffinity() > config: x86_64-lkp (attached as .config) > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > reproduce: > git checkout 88437e0ce11d4b74d9606e2c587cdebbdfb41cf3 > # save the attached .config to linux build tree > make ARCH=x86_64 > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > All errors (new ones prefixed by >>): > > >> ERROR: "tracing_stop" [kernel/rcu/rcutorture.ko] undefined! Apologies, this is an experimental commit not intended for mainline. So it only works when rcutorture is built in. Thanx, Paul
Re: Question about sched_setaffinity()
On Thu, May 09, 2019 at 11:56:35PM +0200, Andrea Parri wrote: > On Thu, May 09, 2019 at 11:40:25PM +0200, Andrea Parri wrote: > > On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote: > > > On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote: > > > > On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote: > > > > > On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote: > > > > > > On Wed, 1 May 2019 12:12:13 -0700 > > > > > > "Paul E. McKenney" wrote: > > > > > > > > > > > > > > > > > > > OK, what I did was to apply the patch at the end of this email to > > > > > > > -rcu > > > > > > > branch dev, then run rcutorture as follows: > > > > > > > > > > > > > > nohup tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 8 > > > > > > > --duration 2 --configs "TRIVIAL" --bootargs > > > > > > > "trace_event=sched:sched_switch,sched:sched_wakeup > > > > > > > ftrace=function_graph > > > > > > > ftrace_graph_filter=sched_setaffinity,migration_cpu_stop" > > > > > > > > > > > > > > This resulted in the console output that I placed here: > > > > > > > > > > > > > > http://www2.rdrop.com/~paulmck/submission/console.log.gz > > > > > > > > > > > > > > But I don't see calls to sched_setaffinity() or > > > > > > > migration_cpu_stop(). > > > > > > > Steve, is something else needed on the kernel command line in > > > > > > > addition to > > > > > > > the following? > > > > > > > > > > > > > > ftrace=function_graph > > > > > > > ftrace_graph_filter=sched_setaffinity,migration_cpu_stop > > > > > > > > > > > > Do you have function graph enabled in the config? > > > > > > > > > > > > [2.098303] ftrace bootup tracer 'function_graph' not registered. > > > > > > > > > > I guess I don't! Thank you, will fix. > > > > > > > > > > Let's see... > > > > > > > > > > My .config has CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y. It looks like I > > > > > need CONFIG_FUNCTION_GRAPH_TRACER=y, which I don't have. And it looks > > > > > like that needs CONFIG_FUNCTION_TRACER=y, which I also don't have. > > > > > But I do have CONFIG_HAVE_FUNCTION_TRACER=y. So I should add this > > > > > to my rcutorture command line: > > > > > > > > > > --kconfig "CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y". > > > > > > > > > > I fired this up. Here is hoping! ;-) > > > > > > > > > > And it does have sched_setaffinity(), woo-hoo!!! I overwrote the old > > > > > file: > > > > > > > > > > http://www2.rdrop.com/~paulmck/submission/console.log.gz > > > > > > > > And I reran after adding a trace_printk(), which shows up as follows: > > > > > > > > [ 211.409565] 6) | /* On unexpected CPU 6, expected > > > > 4!!! */ > > > > > > > > I placed the console log here: > > > > > > > > http://www2.rdrop.com/~paulmck/submission/console.tpk.log.gz > > > > > > > > Just in case the earlier log proves useful. > > > > > > > > And it is acting as if the destination CPU proved to be offline. Except > > > > that this rcutorture scenario doesn't offline anything, and I don't see > > > > any CPU-hotplug removal messages. So I added another trace_printk() to > > > > print out cpu_online_mask. This gets me the following: > > > > > > > > [ 31.565605] 0) | /* On unexpected CPU 0, expected > > > > 1!!! */ > > > > [ 31.565605] 0) | /* Online CPUs: 0-7 */ > > > > > > > > So we didn't make it to CPU 1 despite its being online. I placed the > > > > console log here: > > > > > > > > http://www2.rdrop.com/~paulmck/submission/console.tpkol.log.gz > > > > > > > > Thoughts? > > > > And I can finally see/reproduce it!! > > > > Frankly, no idea how this is happening (I have been staring at these > > traces/functions for hours/days now... ;-/ ) > > > > Adding some "sched" folks in Cc: hopefully, they can shed some light > > about this. > > +Thomas, +Sebastian > > Thread starts here: > > http://lkml.kernel.org/r/20190427180246.ga15...@linux.ibm.com Peter Zijlstra kindly volunteered over IRC to look at this more closely tomorrow (well, today, his time). It is quite strange, though! ;-) Thanx, Paul > Andrea > > > > > > And yes, my only suggestion/approach would be to keep bisecting this > > code with printk*..., 'fun' ;-/ > > > > Andrea >
Re: [GIT PULL] clk changes for the merge window
The pull request you sent on Thu, 9 May 2019 14:15:10 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > tags/clk-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ea5aee6d97fd2d4499b1eebc233861c1def70f06 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PULL REQUEST] i2c for 5.2
The pull request you sent on Thu, 9 May 2019 21:11:55 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-5.2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/45182e4e1f8ac04708ca7508c51d9103f07d81ab Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT] Sparc
The pull request you sent on Thu, 09 May 2019 14:35:31 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git > refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9b6c9e96f941c5ab13dad7278a3622f58e5672fc Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] RTC for 5.2
The pull request you sent on Thu, 9 May 2019 23:03:40 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-5.2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8e4ff713ce313dcabbb60e6ede1ffc193e67631f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v3 09/11] platform/x86: asus-wmi: Control RGB keyboard backlight
On Fri 2019-05-10 00:06:11, Andy Shevchenko wrote: > On Thu, May 9, 2019 at 11:45 PM Dan Murphy wrote: > > On 5/9/19 2:04 PM, Yurii Pavlovskyi wrote: > > We are working on a framework for this. > > > > Please see this series > > https://lore.kernel.org/patchwork/project/lkml/list/?series=390141 > > > > It is still a work in progress > > Side question: > Have you considered to convert existing color LED controllers? (It > seems to me that your proposal lacks of the idea to keep back > compatibility with the existing controllers whre user may create a > sysfs node based on the arbitrary label, while it's good to have > multicolor infrastructure like in your proposal. Did I miss > something?) That's undecided at the moment. We have enough fun trying to figure out reasonable interface... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [GIT PULL] Please pull NFS client updates for Linux 5.2
The pull request you sent on Thu, 9 May 2019 20:37:00 +: > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-5.2-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/06cbd26d312edfe4a83ff541c23f8f866265eb24 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush
- Original Message -
>
>
> On 5/9/19 2:06 PM, Jan Stancek wrote:
> > - Original Message -
> >>
> >> On 5/9/19 11:24 AM, Peter Zijlstra wrote:
> >>> On Thu, May 09, 2019 at 05:36:29PM +, Nadav Amit wrote:
> > On May 9, 2019, at 3:38 AM, Peter Zijlstra
> > wrote:
> > diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
> > index 99740e1dd273..fe768f8d612e 100644
> > --- a/mm/mmu_gather.c
> > +++ b/mm/mmu_gather.c
> > @@ -244,15 +244,20 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
> > unsigned long start, unsigned long end)
> > {
> > /*
> > -* If there are parallel threads are doing PTE changes on same
> > range
> > -* under non-exclusive lock(e.g., mmap_sem read-side) but defer
> > TLB
> > -* flush by batching, a thread has stable TLB entry can fail to
> > flush
> > -* the TLB by observing pte_none|!pte_dirty, for example so
> > flush TLB
> > -* forcefully if we detect parallel PTE batching threads.
> > +* Sensible comment goes here..
> > */
> > - if (mm_tlb_flush_nested(tlb->mm)) {
> > - __tlb_reset_range(tlb);
> > - __tlb_adjust_range(tlb, start, end - start);
> > + if (mm_tlb_flush_nested(tlb->mm) && !tlb->full_mm) {
> > + /*
> > +* Since we're can't tell what we actually should have
> > +* flushed flush everything in the given range.
> > +*/
> > + tlb->start = start;
> > + tlb->end = end;
> > + tlb->freed_tables = 1;
> > + tlb->cleared_ptes = 1;
> > + tlb->cleared_pmds = 1;
> > + tlb->cleared_puds = 1;
> > + tlb->cleared_p4ds = 1;
> > }
> >
> > tlb_flush_mmu(tlb);
> As a simple optimization, I think it is possible to hold multiple
> nesting
> counters in the mm, similar to tlb_flush_pending, for freed_tables,
> cleared_ptes, etc.
>
> The first time you set tlb->freed_tables, you also atomically increase
> mm->tlb_flush_freed_tables. Then, in tlb_flush_mmu(), you just use
> mm->tlb_flush_freed_tables instead of tlb->freed_tables.
> >>> That sounds fraught with races and expensive; I would much prefer to not
> >>> go there for this arguably rare case.
> >>>
> >>> Consider such fun cases as where CPU-0 sees and clears a PTE, CPU-1
> >>> races and doesn't see that PTE. Therefore CPU-0 sets and counts
> >>> cleared_ptes. Then if CPU-1 flushes while CPU-0 is still in mmu_gather,
> >>> it will see cleared_ptes count increased and flush that granularity,
> >>> OTOH if CPU-1 flushes after CPU-0 completes, it will not and potentiall
> >>> miss an invalidate it should have had.
> >>>
> >>> This whole concurrent mmu_gather stuff is horrible.
> >>>
> >>> /me ponders more
> >>>
> >>> So I think the fundamental race here is this:
> >>>
> >>> CPU-0 CPU-1
> >>>
> >>> tlb_gather_mmu(.start=1,tlb_gather_mmu(.start=2,
> >>> .end=3);.end=4);
> >>>
> >>> ptep_get_and_clear_full(2)
> >>> tlb_remove_tlb_entry(2);
> >>> __tlb_remove_page();
> >>> if (pte_present(2)) // nope
> >>>
> >>> tlb_finish_mmu();
> >>>
> >>> // continue without TLBI(2)
> >>> // whoopsie
> >>>
> >>> tlb_finish_mmu();
> >>> tlb_flush() -> TLBI(2)
> >> I'm not quite sure if this is the case Jan really met. But, according to
> >> his test, once correct tlb->freed_tables and tlb->cleared_* are set, his
> >> test works well.
> > My theory was following sequence:
> >
> > t1: map_write_unmap() t2: dummy()
> >
> >map_address = mmap()
> >map_address[i] = 'b'
> >munmap(map_address)
> >downgrade_write(>mmap_sem);
> >unmap_region()
> >tlb_gather_mmu()
> > inc_tlb_flush_pending(tlb->mm);
> >free_pgtables()
> > tlb->freed_tables = 1
> > tlb->cleared_pmds = 1
> >
> > pthread_exit()
> > madvise(thread_stack, 8M,
> > MADV_DONTNEED)
>
> I'm not quite familiar with the implementation detail of pthread_exit(),
> does pthread_exit() call MADV_DONTNEED all the time? I don't see your
> test call it.
It's called by glibc:
https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/allocatestack.c;h=fcbc46f0d796abce8d58970d4a1d3df685981e33;hb=refs/heads/master#l380
https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_create.c;h=18b7bbe7659c027dfd7b0ce3b0c83f54a6f15b18;hb=refs/heads/master#l569
(gdb) bt
#0 madvise () at
Re: [PATCHv2 08/10] vfio/mdev: Improve the create/remove sequence
On Thu, 9 May 2019 18:26:59 +0200 Pierre Morel wrote: > On 09/05/2019 11:06, Cornelia Huck wrote: > > [vfio-ap folks: find a question regarding removal further down] > > > > On Wed, 8 May 2019 22:06:48 + > > Parav Pandit wrote: > > > >>> -Original Message- > >>> From: Cornelia Huck > >>> Sent: Wednesday, May 8, 2019 12:10 PM > >>> To: Parav Pandit > >>> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; > >>> kwankh...@nvidia.com; alex.william...@redhat.com; c...@nvidia.com > >>> Subject: Re: [PATCHv2 08/10] vfio/mdev: Improve the create/remove > >>> sequence > >>> > >>> On Tue, 30 Apr 2019 17:49:35 -0500 > >>> Parav Pandit wrote: > >>> > > ...snip... > > @@ -373,16 +330,15 @@ int mdev_device_remove(struct device *dev, > >>> bool force_remove) > mutex_unlock(_list_lock); > > type = to_mdev_type(mdev->type_kobj); > +mdev_remove_sysfs_files(dev, type); > +device_del(>dev); > parent = mdev->parent; > +ret = parent->ops->remove(mdev); > +if (ret) > +dev_err(>dev, "Remove failed: err=%d\n", ret); > >>> > >>> I think carrying on with removal regardless of the return code of the > >>> ->remove callback makes sense, as it simply matches usual practice. > >>> However, are we sure that every vendor driver works well with that? I > >>> think > >>> it should, as removal from bus unregistration (vs. from the sysfs > >>> file) was always something it could not veto, but have you looked at the > >>> individual drivers? > >>> > >> I looked at following drivers a little while back. > >> Looked again now. > >> > >> drivers/gpu/drm/i915/gvt/kvmgt.c which clears the handle valid in > >> intel_vgpu_release(), which should finish first before remove() is invoked. > >> > >> s390 vfio_ccw_mdev_remove() driver drivers/s390/cio/vfio_ccw_ops.c > >> remove() always returns 0. > >> s39 crypo fails the remove() once vfio_ap_mdev_release marks kvm null, > >> which should finish before remove() is invoked. > > > > That one is giving me a bit of a headache (the ->kvm reference is > > supposed to keep us from detaching while a vm is running), so let's cc: > > the vfio-ap maintainers to see whether they have any concerns. > > > > We are aware of this race and we did correct this in the IRQ patches for > which it would have become a real issue. > We now increment/decrement the KVM reference counter inside open and > release. > Should be right after this. > Tony, what is your take on this? I don't have the bandwidth to think this through properly, but my intuition tells me: this might be more complicated than what Pierre's response suggests. Regards, Halil
Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle
On Thu, May 09, 2019 at 09:37:58PM +, mario.limoncie...@dell.com wrote:
> > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned npss)
> > +{
> > + int ret;
> > +
> > + mutex_lock(>scan_lock);
> > + nvme_start_freeze(ctrl);
> > + nvme_wait_freeze(ctrl);
> > + ret = nvme_set_features(ctrl, NVME_FEAT_POWER_MGMT, npss, NULL, 0,
> > + NULL);
> > + nvme_unfreeze(ctrl);
> > + mutex_unlock(>scan_lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(nvme_set_power);
>
> I believe without memory barriers at the end disks with HMB this will
> still kernel panic (Such as Toshiba BG3).
Well, the mutex has an implied memory barrier, but your HMB explanation
doesn't make much sense to me anyway. The "mb()" in this thread's original
patch is a CPU memory barrier, and the CPU had better not be accessing
HMB memory. Is there something else going on here?
> This still allows D3 which we found at least failed to go into deepest state
> and blocked
> platform s0ix for the following SSDs (maybe others):
> Hynix PC601
> LiteOn CL1
We usually write features to spec first, then quirk non-compliant
devices after.
Re: Question about sched_setaffinity()
On Thu, May 09, 2019 at 11:40:25PM +0200, Andrea Parri wrote: > On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote: > > On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote: > > > On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote: > > > > On Wed, May 01, 2019 at 03:16:55PM -0400, Steven Rostedt wrote: > > > > > On Wed, 1 May 2019 12:12:13 -0700 > > > > > "Paul E. McKenney" wrote: > > > > > > > > > > > > > > > > OK, what I did was to apply the patch at the end of this email to > > > > > > -rcu > > > > > > branch dev, then run rcutorture as follows: > > > > > > > > > > > > nohup tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 8 > > > > > > --duration 2 --configs "TRIVIAL" --bootargs > > > > > > "trace_event=sched:sched_switch,sched:sched_wakeup > > > > > > ftrace=function_graph > > > > > > ftrace_graph_filter=sched_setaffinity,migration_cpu_stop" > > > > > > > > > > > > This resulted in the console output that I placed here: > > > > > > > > > > > > http://www2.rdrop.com/~paulmck/submission/console.log.gz > > > > > > > > > > > > But I don't see calls to sched_setaffinity() or > > > > > > migration_cpu_stop(). > > > > > > Steve, is something else needed on the kernel command line in > > > > > > addition to > > > > > > the following? > > > > > > > > > > > > ftrace=function_graph > > > > > > ftrace_graph_filter=sched_setaffinity,migration_cpu_stop > > > > > > > > > > Do you have function graph enabled in the config? > > > > > > > > > > [2.098303] ftrace bootup tracer 'function_graph' not registered. > > > > > > > > I guess I don't! Thank you, will fix. > > > > > > > > Let's see... > > > > > > > > My .config has CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y. It looks like I > > > > need CONFIG_FUNCTION_GRAPH_TRACER=y, which I don't have. And it looks > > > > like that needs CONFIG_FUNCTION_TRACER=y, which I also don't have. > > > > But I do have CONFIG_HAVE_FUNCTION_TRACER=y. So I should add this > > > > to my rcutorture command line: > > > > > > > > --kconfig "CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y". > > > > > > > > I fired this up. Here is hoping! ;-) > > > > > > > > And it does have sched_setaffinity(), woo-hoo!!! I overwrote the old > > > > file: > > > > > > > > http://www2.rdrop.com/~paulmck/submission/console.log.gz > > > > > > And I reran after adding a trace_printk(), which shows up as follows: > > > > > > [ 211.409565] 6) | /* On unexpected CPU 6, expected 4!!! > > > */ > > > > > > I placed the console log here: > > > > > > http://www2.rdrop.com/~paulmck/submission/console.tpk.log.gz > > > > > > Just in case the earlier log proves useful. > > > > > > And it is acting as if the destination CPU proved to be offline. Except > > > that this rcutorture scenario doesn't offline anything, and I don't see > > > any CPU-hotplug removal messages. So I added another trace_printk() to > > > print out cpu_online_mask. This gets me the following: > > > > > > [ 31.565605] 0) | /* On unexpected CPU 0, expected 1!!! > > > */ > > > [ 31.565605] 0) | /* Online CPUs: 0-7 */ > > > > > > So we didn't make it to CPU 1 despite its being online. I placed the > > > console log here: > > > > > > http://www2.rdrop.com/~paulmck/submission/console.tpkol.log.gz > > > > > > Thoughts? > > And I can finally see/reproduce it!! > > Frankly, no idea how this is happening (I have been staring at these > traces/functions for hours/days now... ;-/ ) > > Adding some "sched" folks in Cc: hopefully, they can shed some light > about this. +Thomas, +Sebastian Thread starts here: http://lkml.kernel.org/r/20190427180246.ga15...@linux.ibm.com Andrea > > And yes, my only suggestion/approach would be to keep bisecting this > code with printk*..., 'fun' ;-/ > > Andrea
