Re: [PATCH v2 4/5] powerpc: Fix duplicate const clang warning in user access code
Le 19/09/2018 à 09:45, Joel Stanley a écrit : On Sat, 15 Sep 2018 at 03:27, Nick Desaulniers wrote: On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley wrote: From: Anton Blanchard This re-applies b91c1e3e7a6f which was reverted in f2ca80905929 d466f6c5cac1 f84ed59a612d (powerpc/sparse: Constify the address pointer ..."). We see a large number of duplicate const errors in the user access code when building with llvm/clang: include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] ret = __get_user(c, uaddr); The problem is we are doing const __typeof__(*(ptr)), which will hit the warning if ptr is marked const. Removing const does not seem to have any effect on GCC code generation. I wouldn't expect it to for a local variable with such localized usage. I myself am quite liberal in applying `const` to everything, so I will try to fix this in Clang as well, but this should silence the warning for users of older versions of Clang and results in no functional change. Reviewed-by: Nick Desaulniers Nick has written a clang patch that suppresses the warning in the same way as GCC. Assuming it gets merged, as we depend on clang-8 we could chose to not merge the kernel patch. https://reviews.llvm.org/D52248 Seems like Michael has merged this patch anyway. Christophe
[PATCH] powerpc/pkeys: Fix reading of ibm, processor-storage-keys property
scan_pkey_feature() uses of_property_read_u32_array() to read the
ibm,processor-storage-keys property and calls be32_to_cpu() on the
value it gets. The problem is that of_property_read_u32_array() already
returns the value converted to the CPU byte order.
The value of pkeys_total ends up more or less sane because there's a min()
call in pkey_initialize() which reduces pkeys_total to 32. So in practice
the kernel ignores the fact that the hypervisor reserved one key for
itself (the device tree advertises 31 keys in my test VM).
This is wrong, but the effect in practice is that when a process tries to
allocate the 32nd key, it gets an -EINVAL error instead of -ENOSPC which
would indicate that there aren't any keys available
Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem")
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/mm/pkeys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
index 333b1f80c435..b271b283c785 100644
--- a/arch/powerpc/mm/pkeys.c
+++ b/arch/powerpc/mm/pkeys.c
@@ -45,7 +45,7 @@ static void scan_pkey_feature(void)
* Since any pkey can be used for data or execute, we will just treat
* all keys as equal and track them as one entity.
*/
- pkeys_total = be32_to_cpu(vals[0]);
+ pkeys_total = vals[0];
pkeys_devtree_defined = true;
}
Re: [PATCH] powerpc/pseries: Track LMB nid instead of using device tree
Nathan Fontenot writes: > When removing memory we need to remove the memory from the node > it was added to instead of looking up the node it should be in > in the device tree. > > During testing we have seen scenarios where the affinity for a > LMB changes due to a partition migration or PRRN event. In these > cases the node the LMB exists in may not match the node the device > tree indicates it belongs in. This can lead to a system crash > when trying to DLAPR remove the LMB after a migration or PRRN > event. The current code looks up the node in the device tree to > remove the LMB from, the crash occurs when we try to offline this > node and it does not have any data, i.e. node_data[nid] == NULL. This isn't building for 32-bit etc: arch/powerpc/mm/drmem.c: In function 'init_drmem_v1_lmbs': arch/powerpc/mm/drmem.c:371:14: error: implicit declaration of function 'memory_add_physaddr_to_nid' [-Werror=implicit-function-declaration] lmb->nid = memory_add_physaddr_to_nid(lmb->base_addr); ^ cc1: all warnings being treated as errors scripts/Makefile.build:317: recipe for target 'arch/powerpc/mm/drmem.o' failed See the failed checks here: https://patchwork.ozlabs.org/patch/969150/ Probably drmem.c should only be compiled for 64-bit NUMA etc. cheers
Re: [PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling
On Tue, Sep 18, 2018 at 04:58:54PM -0500, Bjorn Helgaas wrote: > On Wed, Sep 12, 2018 at 11:55:26AM -0500, Bjorn Helgaas wrote: > > From: Bjorn Helgaas > > > > The original PCI error recovery functionality was for the powerpc-specific > > IBM EEH feature. PCIe subsequently added some similar features, including > > AER and DPC, that can be used on any architecture. > > > > We want the generic PCI core error handling support to work with all of > > these features. Driver error recovery callbacks should be independent of > > which feature the platform provides. > > > > Add the generic PCI core error recovery files to the powerpc EEH > > MAINTAINERS entry so the powerpc folks will be copied on changes to the > > generic PCI error handling strategy. > > > > Signed-off-by: Bjorn Helgaas > > I applied the following to for-linus for v4.19. Russell, if you want > to be removed, let me know and I'll do that. Cheers! Acked-by: Sam Bobroff > commit 3fed0e04026c > Author: Bjorn Helgaas > Date: Wed Sep 12 11:55:26 2018 -0500 > > MAINTAINERS: Update PPC contacts for PCI core error handling > > The original PCI error recovery functionality was for the powerpc-specific > IBM EEH feature. PCIe subsequently added some similar features, including > AER and DPC, that can be used on any architecture. > > We want the generic PCI core error handling support to work with all of > these features. Driver error recovery callbacks should be independent of > which feature the platform provides. > > Add the generic PCI core error recovery files to the powerpc EEH > MAINTAINERS entry so the powerpc folks will be copied on changes to the > generic PCI error handling strategy. > > Add Sam and Oliver as maintainers for this area. > > Signed-off-by: Bjorn Helgaas > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4ece30f15777..f23244003836 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11203,8 +11203,14 @@ F: tools/pci/ > > PCI ENHANCED ERROR HANDLING (EEH) FOR POWERPC > M: Russell Currey > +M: Sam Bobroff > +M: Oliver O'Halloran > L: linuxppc-dev@lists.ozlabs.org > S: Supported > +F: Documentation/PCI/pci-error-recovery.txt > +F: drivers/pci/pcie/aer.c > +F: drivers/pci/pcie/dpc.c > +F: drivers/pci/pcie/err.c > F: Documentation/powerpc/eeh-pci-error-recovery.txt > F: arch/powerpc/kernel/eeh*.c > F: arch/powerpc/platforms/*/eeh*.c > signature.asc Description: PGP signature
Re: [v2] powerpc/configs: Update skiroot defconfig
On Tue, 2018-09-18 at 03:36:17 UTC, Joel Stanley wrote: > Disable new features from recent releases, and clean out some other > unused options: > > - Enable EXPERT, so we can disable some things > - Disable non-powerpc BPF decoders > - Disable TASKSTATS > - Disable unused syscalls > - Set more things to be modules > - Turn off unused network vendors > - PPC_OF_BOOT_TRAMPOLINE and FB_OF are unused on powernv > - Drop unused Radeon and Matrox GPU drivers > - IPV6 support landed in petitboot > - Bringup related command line powersave=off dropped, switch to quiet > > Set CONFIG_I2C_CHARDEV=y as the module is not loaded automatically, and > without this i2cget etc. will fail in the skiroot environment. > > This defconfig gets us build coverage of KERNEL_XZ, which was broken in > the 4.19 merge window for powerpc. > > Signed-off-by: Joel Stanley Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/cbc39809a398b1a30c2bdb0f3123ee cheers
Re: powerpc/fadump: re-register firmware-assisted dump if already registered
On Fri, 2018-09-14 at 14:06:02 UTC, Hari Bathini wrote: > Firmware-Assisted Dump (FADump) needs to be registered again after any > memory hot add/remove operation to update the crash memory ranges. But > currently, the kernel returns '-EEXIST' if we try to register without > uregistering it first. This could expose the system to racing issues > while unregistering and registering FADump from userspace during udev > events. Spare the userspace of this and let it be taken care of in the > kernel space for a simpler interface. > > Since this change, running 'echo 1 > /sys/kernel/fadump_registered' > would result in re-regisering (unregistering and registering) FADump, > if it was already registered. > > Signed-off-by: Hari Bathini > Acked-by: Mahesh Salgaonkar Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/0823c68b054bca9dc321adea829af5 cheers
Re: [01/12] powerpc/64s/hash: Fix stab_rr off by one initialization
On Fri, 2018-09-14 at 15:30:45 UTC, Nicholas Piggin wrote: > This causes SLB alloation to start 1 beyond the start of the SLB. > There is no real problem because after it wraps it stats behaving > properly, it's just surprisig to see when looking at SLB traces. > > Signed-off-by: Nicholas Piggin Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/09b4438db13fa83b6219aee5993711 cheers
Re: powerpc/pseries: Disable CPU hotplug across migrations
On Mon, 2018-09-17 at 19:14:02 UTC, Nathan Fontenot wrote: > When performing partition migrations all present CPUs must be online > as all present CPUs must make the H_JOIN call as part of the migration > process. Once all present CPUs make the H_JOIN call, one CPU is returned > to make the rtas call to perform the migration to the destination system. > > During testing of migration and changing the SMT state we have found > instances where CPUs are offlined, as part of the SMT state change, > before they make the H_JOIN call. This results in a hung system where > every CPU is either in H_JOIN or offline. > > To prevent this this patch disables CPU hotplug during the migration > process. > > Signed-off-by: Nathan Fontenot > Reviewed-by: Tyrel Datwyler Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/85a88cabad57d26d826dd94ea34d3a cheers
Re: [1/3] powerpc: remove old GCC version checks
On Fri, 2018-09-14 at 05:08:52 UTC, Nicholas Piggin wrote: > GCC 4.6 is the minimum supported now. > > Signed-off-by: Nicholas Piggin > Reviewed-by: Joel Stanley Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/f2910f0e6835339e6ce82cef22fa15 cheers
Re: [v2, 4/5] powerpc: Fix duplicate const clang warning in user access code
On Fri, 2018-09-14 at 04:06:48 UTC, Joel Stanley wrote: > From: Anton Blanchard > > This re-applies b91c1e3e7a6f which was reverted in f2ca80905929 > d466f6c5cac1 f84ed59a612d (powerpc/sparse: Constify the address pointer > ..."). > > We see a large number of duplicate const errors in the user access > code when building with llvm/clang: > > include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration > specifier > [-Wduplicate-decl-specifier] > ret = __get_user(c, uaddr); > > The problem is we are doing const __typeof__(*(ptr)), which will hit the > warning if ptr is marked const. > > Removing const does not seem to have any effect on GCC code generation. > > Signed-off-by: Anton Blanchard > Signed-off-by: Joel Stanley > Reviewed-by: Nick Desaulniers Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e00d93ac9a189673028ac125a74b9b cheers
Re: [v2,3/5] powerpc/boot: Ensure _zimage_start is a weak symbol
On Fri, 2018-09-14 at 04:06:47 UTC, Joel Stanley wrote: > When building with clang crt0's _zimage_start is not marked weak, which > breaks the build when linking the kernel image: > > $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$ > 0058 g .text _zimage_start > > ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start': > (.text+0x58): multiple definition of '_zimage_start'; > arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here > > Clang requires the .weak directive to appear after the symbol is > declared. The binutils manual says: > > This directive sets the weak attribute on the comma separated list of > symbol names. If the symbols do not already exist, they will be > created. > > So it appears this is different with clang. The only reference I could > see for this was an OpenBSD mailing list post[1]. > > Changing it to be after the declaration fixes building with Clang, and > still works with GCC. > > $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$ > 0058 w .text _zimage_start > > Reported to clang as https://bugs.llvm.org/show_bug.cgi?id=38921 > > [1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCY > > Signed-off-by: Joel Stanley > Reviewed-by: Nick Desaulniers Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/ee9d21b3b3583712029a0db65a4b7c cheers
Re: PowerPC/VDSO: Correct call frame information
On Fri, 2018-09-14 at 03:40:04 UTC, Alan Modra wrote: > Call Frame Information is used by gdb for back-traces and inserting > breakpoints on function return for the "finish" command. This failed > when inside __kernel_clock_gettime. More concerning than difficulty > debugging is that CFI is also used by stack frame unwinding code to > implement exceptions. If you have an app that needs to handle > asynchronous exceptions for some reason, and you are unlucky enough to > get one inside the VDSO time functions, your app will crash. > > What's wrong: There is control flow in __kernel_clock_gettime that > reaches label 99 without saving lr in r12. CFI info however is > interpreted by the unwinder without reference to control flow: It's a > simple matter of "Execute all the CFI opcodes up to the current > address". That means the unwinder thinks r12 contains the return > address at label 99. Disabuse it of that notion by resetting CFI for > the return address at label 99. > > Note that the ".cfi_restore lr" could have gone anywhere from the > "mtlr r12" a few instructions earlier to the instruction at label 99. > I put the CFI as late as possible, because in general that's best > practice (and if possible grouped with other CFI in order to reduce > the number of CFI opcodes executed when unwinding). Using r12 as the > return address is perfectly fine after the "mtlr r12" since r12 on > that code path still contains the return address. > > __get_datapage also has a CFI error. That function temporarily saves > lr in r0, and reflects that fact with ".cfi_register lr,r0". A later > use of r0 means the CFI at that point isn't correct, as r0 no longer > contains the return address. Fix that too. > > Signed-off-by: Alan Modra > Tested-by: Reza Arbab Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/56d20861c027498b5a1112b4f9f05b cheers
Re: [v2] selftests/powerpc: Do not fail with reschedule
On Wed, 2018-09-12 at 20:31:05 UTC, Breno Leitao wrote: > There are cases where the test is not expecting to have the transaction > aborted, but, the test process might have been rescheduled, either in the > OS level or by KVM (if it is running on a KVM guest machine). The process > reschedule will cause a treclaim/recheckpoint which will cause the > transaction to doom, aborting the transaction as soon as the process is > rescheduled back to the CPU. This might cause the test to fail, but this is > not a failure in essence. > > If that is the case, TEXASR[FC] is indicated with either > TM_CAUSE_RESCHEDULE or TM_CAUSE_KVM_RESCHEDULE for KVM interruptions. > > In this scenario, ignore these two failures and avoid the whole test to > return failure. > > Signed-off-by: Breno Leitao > Reviewed-by: Gustavo Romero Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/44d947eff19d64384efc06069509db cheers
Re: [v10,1/5] powerpc/pseries: Define MCE error event section.
On Tue, 2018-09-11 at 14:26:52 UTC, Mahesh J Salgaonkar wrote: > From: Mahesh Salgaonkar > > On pseries, the machine check error details are part of RTAS extended > event log passed under Machine check exception section. This patch adds > the definition of rtas MCE event section and related helper > functions. > > Signed-off-by: Mahesh Salgaonkar Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/04fce21c9db54695389200b50b0b7a cheers
Re: powerpc/tm: Fix HFSCR bit for no suspend case
On Tue, 2018-09-11 at 03:07:56 UTC, Michael Neuling wrote: > Currently on P9N DD2.1 we end up taking infinite TM facility > unavailable exceptions on the first TM usage by userspace. > > In the special case of TM no suspend (P9N DD2.1), Linux is told TM is > off via CPU dt-ftrs but told to (partially) use it via > OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED. So HFSCR[TM] will be off from > dt-ftrs but we need to turn it on for the no suspend case. > > This patch fixes this by enabling HFSCR TM in this case. > > Cc: sta...@vger.kernel.org # 4.15+ > Signed-off-by: Michael Neuling > Tested-by: Breno Leitao Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/dd9a8c5a87395b6f05552c3b44e42f cheers
Re: [v5,1/2] powerpc/pseries: Remove prrn_work workqueue
On Mon, 2018-09-10 at 14:57:00 UTC, Nathan Fontenot wrote: > When a PRRN event is received we are already running in a worker > thread. Instead of spawning off another worker thread on the prrn_work > workqueue to handle the PRRN event we can just call the PRRN handler > routine directly. > > With this update we can also pass the scope variable for the PRRN > event directly to the handler instead of it being a global variable. > > This patch fixes the following oops mnessage we are seeing in PRRN testing: > > Oops: Bad kernel stack pointer, sig: 6 [#1] > SMP NR_CPUS=2048 NUMA pSeries > Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 > dns_resolver nfs lockd grace sunrpc fscache binfmt_misc reiserfs vfat fat > rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag > netlink_diag af_packet xfs libcrc32c dm_service_time ibmveth(X) ses enclosure > scsi_transport_sas rtc_generic btrfs xor raid6_pq sd_mod ibmvscsi(X) > scsi_transport_srp ipr(X) libata sg dm_multipath dm_mod scsi_dh_rdac > scsi_dh_emc scsi_dh_alua scsi_mod autofs4 > Supported: Yes, External > 54 > CPU: 7 PID: 18967 Comm: kworker/u96:0 Tainted: G X > 4.4.126-94.22-default #1 > Workqueue: pseries hotplug workque pseries_hp_work_fn > task: c00775367790 ti: c0001ebd4000 task.ti: c0070d14 > NIP: LR: 1fb3d050 CTR: > REGS: c0001ebd7d40 TRAP: 0700 Tainted: G X > (4.4.126-94.22-default) > MSR: 800102081000 <41,VEC,ME5 CR: 2802 XER: 20040018 4 > CFAR: 1fb3d084 40 419 13 > GPR00: 400010007 1400 00041fffe200 > GPR04: 00805 1fb15fa8 00050500 > GPR08: 0001f40040001 05:5200040002 > GPR12: 5c7a05400 c00e89f8 1ed9f668 > GPR16: 1fbeff9441fbeff94 1fb545e4 00600060 > GPR20: 4 > GPR24: 540001fb3c000 1fb1b040 > GPR28: 1fb2400041fb440d8 0008 > NIP [] 5 (null) > LR [1fb3d050] 031fb3d050 > Call Trace:4 > Instruction dump: 4 5:47 122 > X4XX > X5XX 6000 6000 6000 6000 > ---[ end trace aa5627b04a7d9d6b ]--- > 3NMI watchdog: BUG: soft lockup - CPU#27 stuck for 23s! [kworker/27:0:13903] > Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 > dns_resolver nfs lockd grace sunrpc fscache binfmt_misc reiserfs vfat fat > rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag > netlink_diag af_packet xfs libcrc32c dm_service_time ibmveth(X) ses enclosure > scsi_transport_sas rtc_generic btrfs xor raid6_pq sd_mod ibmvscsi(X) > scsi_transport_srp ipr(X) libata sg dm_multipath dm_mod scsi_dh_rdac > scsi_dh_emc scsi_dh_alua scsi_mod autofs4 > Supported: Yes, External > CPU: 27 PID: 13903 Comm: kworker/27:0 Tainted: G D X > 4.4.126-94.22-default #1 > Workqueue: events prrn_work_fn > task: c00747cfa390 ti: c0074712c000 task.ti: c0074712c000 > NIP: c08002a8 LR: c0090770 CTR: 0032e088 > REGS: c0074712f7b0 TRAP: 0901 Tainted: G D X > (4.4.126-94.22-default) > MSR: 80019033 CR: 22482044 XER: 2004 > CFAR: c08002c4 SOFTE: 1 > GPR00: c0090770 c0074712fa30 c0f09800 c0fa1928 > 6:02 > GPR04: c00775f5e000 fffe 0001 c0f42db8 > GPR08: 0001 8007 > GPR12: 800621008318 c7a14400 > NIP [c08002a8] _raw_spin_lock+0x68/0xd0 > LR [c0090770] mobility_rtas_call+0x50/0x100 > Call Trace:595 > [c0074712fa60] [c0090770] mobility_rtas_call+0x50/0x100 > [c0074712faf0] [c0090b08] pseries_devicetree_update+0xf8/0x530 > [c0074712fc20] [c0031ba4] prrn_work_fn+0x34/0x50 > [c0074712fc40] [c00e0390] process_one_work+0x1a0/0x4e0 > [c0074712fcd0] [c00e0870] worker_thread+0x1a0/0x6105:57 2 > [c0074712fd80] [c00e8b18] kthread+0x128/0x150 > [c0074712fe30] [c00096f8] ret_from_kernel_thread+0x5c/0x64 > Instruction dump: > 2c09 40c20010 7d40192d 40c2fff0 7c2004ac 2fa9 40de0018 5:540030 3 > e8010010 ebe1fff8 7c0803a6 4e800020 <7c210b78> e92d 89290009 792affe3 > > Signed-off-by: John Allen > Signed-off-by: Haren Myneni Series applied to powerpc next,
Re: [1/2] powerpc/prom: Remove VLA in prom_check_platform_support()
On Wed, 2018-09-05 at 02:09:50 UTC, Suraj Jitindar Singh wrote: > In prom_check_platform_support() we retrieve and parse the > "ibm,arch-vec-5-platform-support" property of the chosen node. > Currently we use a variable length array however to avoid this use an > array of constant length 8. > > This property is used to indicate the supported options of vector 5 > bytes 23-26 of the ibm,architecture.vec node. Each of these options > is a pair of bytes, thus for 4 options we have a max length of 8 bytes. > > Signed-off-by: Suraj Jitindar Singh > Reviewed-by: Joel Stanley Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/ab91239942a900e209f72488627306 cheers
Re: [v2] powerpc/xive: Avoid unitialized variable
On Thu, 2018-08-23 at 23:26:39 UTC, Breno Leitao wrote: > From: Breno Leitao > > Function xive_native_get_ipi() might uses chip_id without it being > initialized. > > This gives the following error on 'smatch' tool: > > error: uninitialized symbol 'chip_id' > > The suggestion is using xc->chip_id instead of consulting the OF for chip id, > which is safe since xive_prepare_cpu() should have initialized ->chip_id by > the time xive_native_get_ipi() is called. > > CC: Cédric Le Goater > Signed-off-by: Breno Leitao > Reviewed-by: Cédric Le Goater Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8ac9e5bfd8cf41ef106ac97267117e cheers
Re: powerpc/iommu: avoid derefence before pointer check
On Tue, 2018-08-21 at 18:44:48 UTC, Breno Leitao wrote: > The tbl pointer is being derefenced by IOMMU_PAGE_SIZE prior the check if > it is not NULL. > > Just moving the dereference code to after the check, where there will be > guarantee that 'tbl' will not be NULL. > > CC: Alistair Popple > Signed-off-by: Breno Leitao Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/984ecdd68de0fa1f63ce205d6c19ef cheers
Re: powerpc/powernv: Don't select the cpufreq governors
On Tue, 2018-08-21 at 02:14:28 UTC, Joel Stanley wrote:
> Deciding wich govenors should be built into the kernel can be left to
> users to configure.
>
> Fixes: 81f359027a3a ("cpufreq: powernv: Select CPUFreq related Kconfig
> options for powernv")
> Signed-off-by: Joel Stanley
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b0dc0f8618e87f1b2c7f04b977fda1
cheers
Re: powerpc/64: Remove static branch hints from memset()
On Tue, 2018-08-21 at 01:04:12 UTC, Anton Blanchard wrote: > From: Anton Blanchard > > Static branch hints override dynamic branch prediction on recent > POWER CPUs. We should only use them when we are overwhelmingly > sure of the direction. > > Signed-off-by: Anton Blanchard Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/be54c1216f6689a6eb504e3471d0cb cheers
Re: [v2,1/3] powerpc/pseries/mm: Introducing FW_FEATURE_BLOCK_REMOVE
On Mon, 2018-08-20 at 14:29:34 UTC, Laurent Dufour wrote: > This feature tells if the hcall H_BLOCK_REMOVE is available. > > Cc: "Aneesh Kumar K.V" > Cc: Nicholas Piggin > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Benjamin Herrenschmidt > Reviewed-by: Aneesh Kumar K.V > Signed-off-by: Laurent Dufour Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/5600fbe340331e2a25d1b277f9c190 cheers
Re: powerpc/memtrace: Remove memory in chunks
On Fri, 2018-08-17 at 04:25:01 UTC, Rashmica Gupta wrote: > When hot-removing memory release_mem_region_adjustable() splits iomem > resources if they are not the exact size of the memory being > hot-deleted. Adding this memory back to the kernel adds a new resource. > > Eg a node has memory 0x0 - 0xf. Hot-removing 1GB from > 0xf4000 results in the single resource 0x0-0xf being split > into two resources: 0x0-0xf3fff and 0xf8000-0xf. > > When we hot-add the memory back we now have three resources: > 0x0-0xf3fff, 0xf4000-0xf7fff, and 0xf8000-0xf. > > This is an issue if we try to remove some memory that overlaps > resources. Eg when trying to remove 2GB at address 0xf4000, > release_mem_region_adjustable() fails as it expects the chunk of memory > to be within the boundaries of a single resource. We then get the > warning: "Unable to release resource" and attempting to use memtrace > again gives us this error: "bash: echo: write error: Resource > temporarily unavailable" > > This patch makes memtrace remove memory in chunks that are always the > same size from an address that is always equal to end_of_memory - > n*size, for some n. So hotremoving and hotadding memory of different > sizes will now not attempt to remove memory that spans multiple > resources. > > Signed-off-by: Rashmica Gupta Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/3f7daf3d7582dc6628ac40a9045dd1 cheers
Re: [V3] ocxl: Fix access to the AFU Descriptor Data
On Tue, 2018-08-14 at 12:45:15 UTC, Christophe Lombard wrote:
> The AFU Information DVSEC capability is a means to extract common,
> general information about all of the AFUs associated with a Function
> independent of the specific functionality that each AFU provides.
> Write in the AFU Index field allows to access to the descriptor data
> for each AFU.
>
> With the current code, we are not able to access to these specific data
> when the index >= 1 because we are writing to the wrong location.
> All requests to the data of each AFU are pointing to those of the AFU 0,
> which could have impacts when using a card with more than one AFU per
> function.
>
> This patch fixes the access to the AFU Descriptor Data indexed by the
> AFU Info Index field.
>
> Fixes: 5ef3166e8a32 ("ocxl: Driver code for 'generic' opencapi devices")
> Cc: stable # 4.16
> Signed-off-by: Christophe Lombard
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6f8e45f7eb1bee5efdbe4a9cfe4a45
cheers
Re: powerpc/selftests: Wait all threads to join
On Tue, 2018-07-31 at 20:55:57 UTC, Breno Leitao wrote: > Test tm-tmspr might exit before all threads stop executing, because it just > waits for the very last thread to join before proceeding/exiting. > > This patch makes sure that all threads that were created will join before > proceeding/exiting. > > This patch also guarantees that the amount of threads being created is equal > to thread_num. > > Signed-off-by: Breno Leitao Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/693b31b2fc1636f0aa7af53136d3b4 cheers
Re: [v2,2/4] powerpc/tm: Fix HTM documentation
On Mon, 2018-06-18 at 22:59:42 UTC, Breno Leitao wrote:
> This patch simply fix part of the documentation on the HTM code.
>
> This fixes reference to old fields that were renamed in commit
> 000ec280e3dd ("powerpc: tm: Rename transct_(*) to ck(\1)_state")
>
> It also documents better the flow after commit eb5c3f1c8647 ("powerpc:
> Always save/restore checkpointed regs during treclaim/trecheckpoint"),
> where tm_recheckpoint can recheckpoint what is in ck{fp,vr}_state blindly.
>
> Signed-off-by: Breno Leitao
> Acked-By: Michael Neuling
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/96695563cebfb810b09479a9951ebb
cheers
Re: pseries/memory-hotplug: Only update DT once per memory DLPAR request
On Fri, 2018-04-20 at 20:29:48 UTC, Nathan Fontenot wrote: > The updates to powerpc numa and memory hotplug code now use the > in-kernel LMB array instead of the device tree. This change > allows the pseries memory DLPAR code to only update the device > tree once after successfully handling a DLPAR request. > > Prior to the in-kernel LMB array, the numa code looked up the > affinity for memory being added in the device tree, the code > now looks this up in the LMB array. This change means the > memory hotplug code can just update the affinity for an LMB > in the LMB array instead of updating the device tree. > > This also provides a savings in kernel memory. When updating the > device tree old properties are never free'ed since there is no > usecount on properties. This behavior leads to a new copy of the > property being allocated every time a LMB is added or removed > (i.e. a request to add 100 LMBs creates 100 new copies of the > property). With this update only a single new property is created > when a DLPAR request completes successfully. > > Signed-off-by: Nathan Fontenot Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/063b8b1251fd069f3740339fca5611 cheers
Re: [PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
From: YueHaibing Date: Wed, 19 Sep 2018 18:23:39 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. > > Found by coccinelle. > > Signed-off-by: YueHaibing Applied.
Re: Checkpatch bad Warning (Re: [PATCH] powerpc/kgdb: add kgdb_arch_set/remove_breakpoint())
On Tue, 2018-09-18 at 09:33 +, Christophe Leroy wrote: > On the below patch, checkpatch reports > > WARNING: struct kgdb_arch should normally be const > #127: FILE: arch/powerpc/kernel/kgdb.c:480: > +struct kgdb_arch arch_kgdb_ops; > > But when I add 'const', I get compilation failure So don't add const. checkpatch is stupid. You are not. _Always_ take checkpatch bleats with very large grains of salt. Perhaps send a patch to remove kgbd_arch from scripts/const_structs.checkpatch as it seems not ever to be const.
[PATCH -next] tty: serial: remove set but not used variable 'error'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/tty/serial/pmac_zilog.c: In function 'pmz_receive_chars':
drivers/tty/serial/pmac_zilog.c:222:30: warning:
variable 'error' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
drivers/tty/serial/pmac_zilog.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index a4ec22d..a9d4098 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -219,7 +219,7 @@ static void pmz_interrupt_control(struct uart_pmac_port
*uap, int enable)
static bool pmz_receive_chars(struct uart_pmac_port *uap)
{
struct tty_port *port;
- unsigned char ch, r1, drop, error, flag;
+ unsigned char ch, r1, drop, flag;
int loops = 0;
/* Sanity check, make sure the old bug is no longer happening */
@@ -231,7 +231,6 @@ static bool pmz_receive_chars(struct uart_pmac_port *uap)
port = >port.state->port;
while (1) {
- error = 0;
drop = 0;
r1 = read_zsreg(uap, R1);
@@ -273,7 +272,6 @@ static bool pmz_receive_chars(struct uart_pmac_port *uap)
uap->port.icount.rx++;
if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR | BRK_ABRT)) {
- error = 1;
if (r1 & BRK_ABRT) {
pmz_debug("pmz: got break !\n");
r1 &= ~(PAR_ERR | CRC_ERR);
Re: [PATCH v2 1/2] sched: move stack_canary field at the top of task_struct
Christophe LEROY writes: > Le 19/09/2018 à 13:58, Peter Zijlstra a écrit : >> On Wed, Sep 19, 2018 at 11:14:43AM +, Christophe Leroy wrote: >>> In order to allow the use of non global stack protector canary, >>> the stack canary needs to be located at a know offset defined >>> in Makefile via -mstack-protector-guard-offset. >>> >>> On powerpc/32, register r2 points to current task_struct at >>> all time, the stack_canary located inside task_struct can be >>> used directly if it is located in a known place. >>> >>> In order to allow that, this patch moves the stack_canary field >>> out of the randomized area of task_struct. >> >> And you cannot use something like asm-offsets to extract this? > > I have not been able to find a way to define the compilation flags AFTER > building asm-offsets.h, see https://patchwork.ozlabs.org/patch/971521/ > > If you have a suggestion, it is welcomed. Hmm, that's something of a hard problem. But the stack canary is one of the things we really *do* want to be randomised, so we should probably try to come up with a solution. cheers
Re: [PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling
Bjorn Helgaas writes: > On Wed, Sep 12, 2018 at 11:55:26AM -0500, Bjorn Helgaas wrote: >> From: Bjorn Helgaas >> >> The original PCI error recovery functionality was for the powerpc-specific >> IBM EEH feature. PCIe subsequently added some similar features, including >> AER and DPC, that can be used on any architecture. >> >> We want the generic PCI core error handling support to work with all of >> these features. Driver error recovery callbacks should be independent of >> which feature the platform provides. >> >> Add the generic PCI core error recovery files to the powerpc EEH >> MAINTAINERS entry so the powerpc folks will be copied on changes to the >> generic PCI error handling strategy. > > I really want to make sure the powerpc folks are plugged into any PCI core > error handling discussions. Please let me know if there's a better way > than this patch, or if there are other people who should be added. Yeah this is a good option. We powerpc folks also need to do a better job of keeping an eye on PCI patches, I've asked more of us to subscribe to linux-pci. cheers
Re: [PATCH] MAINTAINERS: Add PPC contacts for PCI core error handling
On Wed, Sep 19, 2018 at 11:49:26AM +1000, Russell Currey wrote: > On Tue, 2018-09-18 at 16:58 -0500, Bjorn Helgaas wrote: > > On Wed, Sep 12, 2018 at 11:55:26AM -0500, Bjorn Helgaas wrote: > > > From: Bjorn Helgaas > > > > > > The original PCI error recovery functionality was for the powerpc-specific > > > IBM EEH feature. PCIe subsequently added some similar features, including > > > AER and DPC, that can be used on any architecture. > > > > > > We want the generic PCI core error handling support to work with all of > > > these features. Driver error recovery callbacks should be independent of > > > which feature the platform provides. > > > > > > Add the generic PCI core error recovery files to the powerpc EEH > > > MAINTAINERS entry so the powerpc folks will be copied on changes to the > > > generic PCI error handling strategy. > > > > > > Signed-off-by: Bjorn Helgaas > > > > I applied the following to for-linus for v4.19. Russell, if you want > > to be removed, let me know and I'll do that. > > Oliver's email address for kernel stuff is ooh...@gmail.com, I think benh has > been > CCing his IBM address. But other than that, > > Acked-by: Russell Currey I updated Oliver's email address and added your ack, thanks!
Re: [PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
Hi Yue, On 09/19/2018 03:23 AM, YueHaibing wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. > > Found by coccinelle. > > Signed-off-by: YueHaibing I tested this against Linux-4.19-rc4, and it seemed to work OK. Please remove the irrelevant line 'Found by coccinelle.' from the commit message. With that change: Acked-by: Geoff Levand -Geoff
Re: [PATCH v2 2/2] powerpc/32: add stack protector support
On Wed, Sep 19, 2018 at 04:22:52PM +0200, Christophe LEROY wrote: > >It looks like it will be easy to enable on 64 bit as well. > > Will it ? It seems that PPC64 doesn't have r2 pointing to current task > struct, but instead it has r13 pointing to the paca struct. Which means > we should add a canary in the paca struct, and populate it at task > switch from current->stack_canary. Or am I missing something ? No, I am just forgetting things :-) > >>+ /* Try to get a semi random initial value. */ > >>+ get_random_bytes(, sizeof(canary)); > >>+ canary ^= mftb(); > >>+ canary ^= LINUX_VERSION_CODE; > > > >These last two lines are useless (or worse, they may give people the idea > >that they are not!) > > Well, the last line is in all arches except x86 > The mftb() was suggested by Michael to add some entropy. > x86 does the same sort of thing with their rdtsc() > > > > >You should use wait_for_random_bytes I think. > > On the 8xx, it takes several minutes before crnd_is_ready(), while > boot_init_stack_canary() is called quite early in start_kernel() If you do not provide real entropy to the canary, the canary doesn't help providing protection as much as you may hope. Segher
Re: [PATCH v2 2/2] powerpc/32: add stack protector support
Le 19/09/2018 à 15:26, Segher Boessenkool a écrit : On Wed, Sep 19, 2018 at 11:14:45AM +, Christophe Leroy wrote: --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -112,6 +112,10 @@ KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION) KBUILD_ARFLAGS+= --target=elf$(BITS)-$(GNUTARGET) endif +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard=tls +cflags-$(CONFIG_STACKPROTECTOR)+= -mstack-protector-guard-reg=r2 +cflags-$(CONFIG_STACKPROTECTOR)+= -mstack-protector-guard-offset=4 This last line is only correct if !CONFIG_THREAD_INFO_IN_TASK; is that always true? Add an assert somewhere maybe? At the time being powerpc doesn't select CONFIG_THREAD_INFO_IN_TASK. A BUILD_BUG_ON() is added in stackprotector.h + /* +* The stack_canary must be located at the offset given to +* -mstack-protector-guard-offset in the Makefile +*/ + BUILD_BUG_ON(offsetof(struct task_struct, stack_canary) != sizeof(long)); Well this will help :-) It looks like it will be easy to enable on 64 bit as well. Will it ? It seems that PPC64 doesn't have r2 pointing to current task struct, but instead it has r13 pointing to the paca struct. Which means we should add a canary in the paca struct, and populate it at task switch from current->stack_canary. Or am I missing something ? + /* Try to get a semi random initial value. */ + get_random_bytes(, sizeof(canary)); + canary ^= mftb(); + canary ^= LINUX_VERSION_CODE; These last two lines are useless (or worse, they may give people the idea that they are not!) Well, the last line is in all arches except x86 The mftb() was suggested by Michael to add some entropy. x86 does the same sort of thing with their rdtsc() You should use wait_for_random_bytes I think. On the 8xx, it takes several minutes before crnd_is_ready(), while boot_init_stack_canary() is called quite early in start_kernel() Christophe
Re: [PATCH v2 2/2] powerpc/32: add stack protector support
On Wed, Sep 19, 2018 at 11:14:45AM +, Christophe Leroy wrote: > --- a/arch/powerpc/Makefile > +++ b/arch/powerpc/Makefile > @@ -112,6 +112,10 @@ KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION) > KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET) > endif > > +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard=tls > +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard-reg=r2 > +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard-offset=4 This last line is only correct if !CONFIG_THREAD_INFO_IN_TASK; is that always true? Add an assert somewhere maybe? > + /* > + * The stack_canary must be located at the offset given to > + * -mstack-protector-guard-offset in the Makefile > + */ > + BUILD_BUG_ON(offsetof(struct task_struct, stack_canary) != > sizeof(long)); Well this will help :-) It looks like it will be easy to enable on 64 bit as well. > + /* Try to get a semi random initial value. */ > + get_random_bytes(, sizeof(canary)); > + canary ^= mftb(); > + canary ^= LINUX_VERSION_CODE; These last two lines are useless (or worse, they may give people the idea that they are not!) You should use wait_for_random_bytes I think. Segher
Re: [PATCH v2 1/2] sched: move stack_canary field at the top of task_struct
On Wed, Sep 19, 2018 at 02:25:00PM +0200, Christophe LEROY wrote: > I have not been able to find a way to define the compilation flags AFTER > building asm-offsets.h, see https://patchwork.ozlabs.org/patch/971521/ > > If you have a suggestion, it is welcomed. Not really; I always get lost in that stuff :/ > > Might as well put it before state, right after the task_info thing. > > > > Yes, it doesn't make much difference, don't any arch expect state at offset > 0 ? Uhmm.. dunno. I would not expect so, but then I didn't check.
Re: [PATCH v2 1/2] sched: move stack_canary field at the top of task_struct
Le 19/09/2018 à 13:58, Peter Zijlstra a écrit :
On Wed, Sep 19, 2018 at 11:14:43AM +, Christophe Leroy wrote:
In order to allow the use of non global stack protector canary,
the stack canary needs to be located at a know offset defined
in Makefile via -mstack-protector-guard-offset.
On powerpc/32, register r2 points to current task_struct at
all time, the stack_canary located inside task_struct can be
used directly if it is located in a known place.
In order to allow that, this patch moves the stack_canary field
out of the randomized area of task_struct.
And you cannot use something like asm-offsets to extract this?
I have not been able to find a way to define the compilation flags AFTER
building asm-offsets.h, see https://patchwork.ozlabs.org/patch/971521/
If you have a suggestion, it is welcomed.
Signed-off-by: Christophe Leroy
---
include/linux/sched.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 977cb57d7bc9..1d977b8a4bac 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -601,6 +601,10 @@ struct task_struct {
/* -1 unrunnable, 0 runnable, >0 stopped: */
volatile long state;
+#ifdef CONFIG_STACKPROTECTOR
+ /* Canary value for the -fstack-protector GCC feature: */
+ unsigned long stack_canary;
+#endif
/*
* This begins the randomizable portion of task_struct. Only
* scheduling-critical items should be added above here.
Might as well put it before state, right after the task_info thing.
Yes, it doesn't make much difference, don't any arch expect state at
offset 0 ?
Christophe
Re: [PATCH v2 1/2] sched: move stack_canary field at the top of task_struct
On Wed, Sep 19, 2018 at 11:14:43AM +, Christophe Leroy wrote:
> In order to allow the use of non global stack protector canary,
> the stack canary needs to be located at a know offset defined
> in Makefile via -mstack-protector-guard-offset.
>
> On powerpc/32, register r2 points to current task_struct at
> all time, the stack_canary located inside task_struct can be
> used directly if it is located in a known place.
>
> In order to allow that, this patch moves the stack_canary field
> out of the randomized area of task_struct.
And you cannot use something like asm-offsets to extract this?
> Signed-off-by: Christophe Leroy
> ---
> include/linux/sched.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 977cb57d7bc9..1d977b8a4bac 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -601,6 +601,10 @@ struct task_struct {
> /* -1 unrunnable, 0 runnable, >0 stopped: */
> volatile long state;
>
> +#ifdef CONFIG_STACKPROTECTOR
> + /* Canary value for the -fstack-protector GCC feature: */
> + unsigned long stack_canary;
> +#endif
> /*
>* This begins the randomizable portion of task_struct. Only
>* scheduling-critical items should be added above here.
Might as well put it before state, right after the task_info thing.
[PATCH v2 2/2] powerpc/32: add stack protector support
This functionality was tentatively added in the past
(commit 6533b7c16ee5 ("powerpc: Initial stack protector
(-fstack-protector) support")) but had to be reverted
(commit f2574030b0e3 ("powerpc: Revert the initial stack
protector support") because of GCC implementing it differently
whether it had been built with libc support or not.
Now, GCC offers the possibility to manually set the
stack-protector mode (global or tls) regardless of libc support.
This time, the patch selects HAVE_STACKPROTECTOR only if
-mstack-protector-guard=global is supported by GCC.
On PPC32, as register r2 points to current task_struct at
all time, the stack_canary located inside task_struct can be
used directly by using the following GCC options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=r2
-mstack-protector-guard-offset=4
(= offsetof(struct task_struct, stack_canary))
$ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT
[ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is
corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64
[ 134.943666]
[ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted
4.18.0-s3k-dev-12143-ga3272be41209 #835
[ 134.963380] Call Trace:
[ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable)
[ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260
[ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64
[ 134.982769] [c6615e00] [] 0x
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 4
arch/powerpc/include/asm/stackprotector.h | 38 +++
arch/powerpc/kernel/Makefile | 4
4 files changed, 47 insertions(+)
create mode 100644 arch/powerpc/include/asm/stackprotector.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a80669209155..538bb6e2fd70 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -180,6 +180,7 @@ config PPC
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_CBPF_JITif !PPC64
+ select HAVE_STACKPROTECTOR if PPC32 &&
$(cc-option,-mstack-protector-guard=tls)
select HAVE_CONTEXT_TRACKINGif PPC64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DEBUG_STACKOVERFLOW
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 11a1acba164a..1108981292e9 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -112,6 +112,10 @@ KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
endif
+cflags-$(CONFIG_STACKPROTECTOR)+= -mstack-protector-guard=tls
+cflags-$(CONFIG_STACKPROTECTOR)+= -mstack-protector-guard-reg=r2
+cflags-$(CONFIG_STACKPROTECTOR)+= -mstack-protector-guard-offset=4
+
LDFLAGS_vmlinux-y := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
LDFLAGS_vmlinux:= $(LDFLAGS_vmlinux-y)
diff --git a/arch/powerpc/include/asm/stackprotector.h
b/arch/powerpc/include/asm/stackprotector.h
new file mode 100644
index ..4fdecbdd78e7
--- /dev/null
+++ b/arch/powerpc/include/asm/stackprotector.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * GCC stack protector support.
+ *
+ */
+
+#ifndef _ASM_STACKPROTECTOR_H
+#define _ASM_STACKPROTECTOR_H
+
+#include
+#include
+#include
+
+/*
+ * Initialize the stackprotector canary value.
+ *
+ * NOTE: this must only be called from functions that never return,
+ * and it must always be inlined.
+ */
+static __always_inline void boot_init_stack_canary(void)
+{
+ unsigned long canary;
+
+ /*
+* The stack_canary must be located at the offset given to
+* -mstack-protector-guard-offset in the Makefile
+*/
+ BUILD_BUG_ON(offsetof(struct task_struct, stack_canary) !=
sizeof(long));
+
+ /* Try to get a semi random initial value. */
+ get_random_bytes(, sizeof(canary));
+ canary ^= mftb();
+ canary ^= LINUX_VERSION_CODE;
+
+ current->stack_canary = canary;
+}
+
+#endif /* _ASM_STACKPROTECTOR_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3b66f2c19c84..0556a7243d2a 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -20,6 +20,10 @@ CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+# -fstack-protector triggers protection checks in this code,
+# but it is being used too early to link to meaningful stack_chk logic.
+CFLAGS_prom_init.o += $(call cc-option, -fno-stack-protector)
+
ifdef CONFIG_FUNCTION_TRACER
# Do not trace early boot code
CFLAGS_REMOVE_cputable.o = -mno-sched-epilog $(CC_FLAGS_FTRACE)
--
2.13.3
[PATCH v2 1/2] sched: move stack_canary field at the top of task_struct
In order to allow the use of non global stack protector canary,
the stack canary needs to be located at a know offset defined
in Makefile via -mstack-protector-guard-offset.
On powerpc/32, register r2 points to current task_struct at
all time, the stack_canary located inside task_struct can be
used directly if it is located in a known place.
In order to allow that, this patch moves the stack_canary field
out of the randomized area of task_struct.
Signed-off-by: Christophe Leroy
---
include/linux/sched.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 977cb57d7bc9..1d977b8a4bac 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -601,6 +601,10 @@ struct task_struct {
/* -1 unrunnable, 0 runnable, >0 stopped: */
volatile long state;
+#ifdef CONFIG_STACKPROTECTOR
+ /* Canary value for the -fstack-protector GCC feature: */
+ unsigned long stack_canary;
+#endif
/*
* This begins the randomizable portion of task_struct. Only
* scheduling-critical items should be added above here.
@@ -746,10 +750,6 @@ struct task_struct {
pid_t pid;
pid_t tgid;
-#ifdef CONFIG_STACKPROTECTOR
- /* Canary value for the -fstack-protector GCC feature: */
- unsigned long stack_canary;
-#endif
/*
* Pointers to the (original) parent process, youngest child, younger
sibling,
* older sibling, respectively. (p->father can be replaced with
--
2.13.3
Re: [RFC PATCH 03/29] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, Sep 19, 2018 at 11:45:07AM +0100, Jonathan Cameron wrote:
> On Wed, 19 Sep 2018 13:34:57 +0300
> Mike Rapoport wrote:
>
> > Hi Jonathan,
> >
> > On Wed, Sep 19, 2018 at 10:04:49AM +0100, Jonathan Cameron wrote:
> > > On Wed, 5 Sep 2018 18:59:18 +0300
> > > Mike Rapoport wrote:
> > >
> > > > All architecures use memblock for early memory management. There is no
> > > > need
> > > > for the CONFIG_HAVE_MEMBLOCK configuration option.
> > > >
> > > > Signed-off-by: Mike Rapoport
> > >
> > > Hi Mike,
> > >
> > > A minor editing issue in here that is stopping boot on arm64 platforms
> > > with latest
> > > version of the mm tree.
> >
> > Can you please try the following patch:
> >
> >
> > From 079bd5d24a01df3df9500d0a33d89cb9f7da4588 Mon Sep 17 00:00:00 2001
> > From: Mike Rapoport
> > Date: Wed, 19 Sep 2018 13:29:27 +0300
> > Subject: [PATCH] of/fdt: fixup #ifdefs after removal of HAVE_MEMBLOCK config
> > option
> >
> > The removal of HAVE_MEMBLOCK configuration option, mistakenly dropped the
> > wrong #endif. This patch restores that #endif and removes the part that
> > should have been actually removed, starting from #else and up to the
> > correct #endif
> >
> > Reported-by: Jonathan Cameron
> > Signed-off-by: Mike Rapoport
>
> Hi Mike,
>
> That's identical to the local patch I'm carrying to fix this so looks good to
> me.
>
> For what it's worth given you'll probably fold this into the larger patch.
>
> Tested-by: Jonathan Cameron
Well, this is up to Andrew now, as the broken patch is already in the -mm
tree.
> Thanks for the quick reply.
>
> Jonathan
>
> > ---
> > drivers/of/fdt.c | 21 +
> > 1 file changed, 1 insertion(+), 20 deletions(-)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 48314e9..bb532aa 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -1119,6 +1119,7 @@ int __init early_init_dt_scan_chosen(unsigned long
> > node, const char *uname,
> > #endif
> > #ifndef MAX_MEMBLOCK_ADDR
> > #define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
> > +#endif
> >
> > void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> > {
> > @@ -1175,26 +1176,6 @@ int __init __weak
> > early_init_dt_reserve_memory_arch(phys_addr_t base,
> > return memblock_reserve(base, size);
> > }
> >
> > -#else
> > -void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> > -{
> > - WARN_ON(1);
> > -}
> > -
> > -int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64
> > size)
> > -{
> > - return -ENOSYS;
> > -}
> > -
> > -int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> > - phys_addr_t size, bool nomap)
> > -{
> > - pr_err("Reserved memory not supported, ignoring range %pa - %pa%s\n",
> > - , , nomap ? " (nomap)" : "");
> > - return -ENOSYS;
> > -}
> > -#endif
> > -
> > static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> > {
> > return memblock_alloc(size, align);
>
>
--
Sincerely yours,
Mike.
Re: [RFC PATCH 03/29] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, 19 Sep 2018 13:34:57 +0300
Mike Rapoport wrote:
> Hi Jonathan,
>
> On Wed, Sep 19, 2018 at 10:04:49AM +0100, Jonathan Cameron wrote:
> > On Wed, 5 Sep 2018 18:59:18 +0300
> > Mike Rapoport wrote:
> >
> > > All architecures use memblock for early memory management. There is no
> > > need
> > > for the CONFIG_HAVE_MEMBLOCK configuration option.
> > >
> > > Signed-off-by: Mike Rapoport
> >
> > Hi Mike,
> >
> > A minor editing issue in here that is stopping boot on arm64 platforms with
> > latest
> > version of the mm tree.
>
> Can you please try the following patch:
>
>
> From 079bd5d24a01df3df9500d0a33d89cb9f7da4588 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Wed, 19 Sep 2018 13:29:27 +0300
> Subject: [PATCH] of/fdt: fixup #ifdefs after removal of HAVE_MEMBLOCK config
> option
>
> The removal of HAVE_MEMBLOCK configuration option, mistakenly dropped the
> wrong #endif. This patch restores that #endif and removes the part that
> should have been actually removed, starting from #else and up to the
> correct #endif
>
> Reported-by: Jonathan Cameron
> Signed-off-by: Mike Rapoport
Hi Mike,
That's identical to the local patch I'm carrying to fix this so looks good to
me.
For what it's worth given you'll probably fold this into the larger patch.
Tested-by: Jonathan Cameron
Thanks for the quick reply.
Jonathan
> ---
> drivers/of/fdt.c | 21 +
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 48314e9..bb532aa 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1119,6 +1119,7 @@ int __init early_init_dt_scan_chosen(unsigned long
> node, const char *uname,
> #endif
> #ifndef MAX_MEMBLOCK_ADDR
> #define MAX_MEMBLOCK_ADDR((phys_addr_t)~0)
> +#endif
>
> void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> @@ -1175,26 +1176,6 @@ int __init __weak
> early_init_dt_reserve_memory_arch(phys_addr_t base,
> return memblock_reserve(base, size);
> }
>
> -#else
> -void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> -{
> - WARN_ON(1);
> -}
> -
> -int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
> -{
> - return -ENOSYS;
> -}
> -
> -int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> - phys_addr_t size, bool nomap)
> -{
> - pr_err("Reserved memory not supported, ignoring range %pa - %pa%s\n",
> - , , nomap ? " (nomap)" : "");
> - return -ENOSYS;
> -}
> -#endif
> -
> static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> {
> return memblock_alloc(size, align);
Re: [RFC PATCH 03/29] mm: remove CONFIG_HAVE_MEMBLOCK
Hi Jonathan,
On Wed, Sep 19, 2018 at 10:04:49AM +0100, Jonathan Cameron wrote:
> On Wed, 5 Sep 2018 18:59:18 +0300
> Mike Rapoport wrote:
>
> > All architecures use memblock for early memory management. There is no need
> > for the CONFIG_HAVE_MEMBLOCK configuration option.
> >
> > Signed-off-by: Mike Rapoport
>
> Hi Mike,
>
> A minor editing issue in here that is stopping boot on arm64 platforms with
> latest
> version of the mm tree.
Can you please try the following patch:
>From 079bd5d24a01df3df9500d0a33d89cb9f7da4588 Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 19 Sep 2018 13:29:27 +0300
Subject: [PATCH] of/fdt: fixup #ifdefs after removal of HAVE_MEMBLOCK config
option
The removal of HAVE_MEMBLOCK configuration option, mistakenly dropped the
wrong #endif. This patch restores that #endif and removes the part that
should have been actually removed, starting from #else and up to the
correct #endif
Reported-by: Jonathan Cameron
Signed-off-by: Mike Rapoport
---
drivers/of/fdt.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 48314e9..bb532aa 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1119,6 +1119,7 @@ int __init early_init_dt_scan_chosen(unsigned long node,
const char *uname,
#endif
#ifndef MAX_MEMBLOCK_ADDR
#define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
+#endif
void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
{
@@ -1175,26 +1176,6 @@ int __init __weak
early_init_dt_reserve_memory_arch(phys_addr_t base,
return memblock_reserve(base, size);
}
-#else
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
-{
- WARN_ON(1);
-}
-
-int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
-{
- return -ENOSYS;
-}
-
-int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
- phys_addr_t size, bool nomap)
-{
- pr_err("Reserved memory not supported, ignoring range %pa - %pa%s\n",
- , , nomap ? " (nomap)" : "");
- return -ENOSYS;
-}
-#endif
-
static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
{
return memblock_alloc(size, align);
--
2.7.4
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 76c83c1..bd841bb 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -1115,13 +1115,11 @@ int __init early_init_dt_scan_chosen(unsigned long
> > node, const char *uname,
> > return 1;
> > }
> >
> > -#ifdef CONFIG_HAVE_MEMBLOCK
> > #ifndef MIN_MEMBLOCK_ADDR
> > #define MIN_MEMBLOCK_ADDR __pa(PAGE_OFFSET)
> > #endif
> > #ifndef MAX_MEMBLOCK_ADDR
> > #define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
> > -#endif
>
> This isn't the right #endif. It is matching with the #ifndef MAX_MEMBLOCK_ADDR
> not the intented #ifdef CONFIG_HAVE_MEMBLOCK.
>
> Now I haven't chased through the exact reason this is causing my acpi
> arm64 system not to boot on the basis it is obviously miss-matched anyway
> and I'm inherently lazy. It's resulting in stubs replacing the following weak
> functions.
>
> early_init_dt_add_memory_arch
> (this is defined elsewhere for some architectures but not arm)
>
> early_init_dt_mark_hotplug_memory_arch
> (there is only one definition of this in the kernel so it doesn't
> need to be weak or in the header etc).
>
> early_init_dt_reserve_memory_arch
> (defined on mips but nothing else)
>
> Taking out the right endif also lets you drop an #else removing some stub
> functions further down in here.
>
> Nice cleanup in general btw.
>
> Thanks,
>
> Jonathan
> >
> > void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> > {
>
--
Sincerely yours,
Mike.
[PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 4 ++--
drivers/net/ethernet/toshiba/ps3_gelic_net.h | 2 +-
drivers/net/ethernet/toshiba/spider_net.c| 4 ++--
drivers/net/ethernet/toshiba/tc35815.c | 6 --
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 88d74ae..75237c8 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -845,9 +845,9 @@ static int gelic_card_kick_txdma(struct gelic_card *card,
* @skb: packet to send out
* @netdev: interface device structure
*
- * returns 0 on success, <0 on failure
+ * returns NETDEV_TX_OK on success, NETDEV_TX_BUSY on failure
*/
-int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
+netdev_tx_t gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
{
struct gelic_card *card = netdev_card(netdev);
struct gelic_descr *descr;
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
index 003d045..fbbf9b5 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
@@ -370,7 +370,7 @@ static inline void udbg_shutdown_ps3gelic(void) {}
void gelic_card_down(struct gelic_card *card);
int gelic_net_open(struct net_device *netdev);
int gelic_net_stop(struct net_device *netdev);
-int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
+netdev_tx_t gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
void gelic_net_set_multi(struct net_device *netdev);
void gelic_net_tx_timeout(struct net_device *netdev);
int gelic_net_setup_netdev(struct net_device *netdev, struct gelic_card *card);
diff --git a/drivers/net/ethernet/toshiba/spider_net.c
b/drivers/net/ethernet/toshiba/spider_net.c
index d925b82..2341726 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -880,9 +880,9 @@
* @skb: packet to send out
* @netdev: interface device structure
*
- * returns 0 on success, !0 on failure
+ * returns NETDEV_TX_OK on success, NETDEV_TX_BUSY on failure
*/
-static int
+static netdev_tx_t
spider_net_xmit(struct sk_buff *skb, struct net_device *netdev)
{
int cnt;
diff --git a/drivers/net/ethernet/toshiba/tc35815.c
b/drivers/net/ethernet/toshiba/tc35815.c
index 7163a8d..6a71c2c 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -474,7 +474,8 @@ static void free_rxbuf_skb(struct pci_dev *hwdev, struct
sk_buff *skb, dma_addr_
/* Index to functions, as function prototypes. */
static int tc35815_open(struct net_device *dev);
-static int tc35815_send_packet(struct sk_buff *skb, struct net_device
*dev);
+static netdev_tx_t tc35815_send_packet(struct sk_buff *skb,
+ struct net_device *dev);
static irqreturn_t tc35815_interrupt(int irq, void *dev_id);
static int tc35815_rx(struct net_device *dev, int limit);
static int tc35815_poll(struct napi_struct *napi, int budget);
@@ -1248,7 +1249,8 @@ static void tc35815_tx_timeout(struct net_device *dev)
* invariant will hold if you make sure that the netif_*_queue()
* calls are done at the proper times.
*/
-static int tc35815_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+tc35815_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct tc35815_local *lp = netdev_priv(dev);
struct TxFD *txfd;
--
1.8.3.1
[PATCH 1/2] iommu: Tidy up window attributes
The external interface to get/set window attributes is already
abstracted behind iommu_domain_{get,set}_attr(), so there's no real
reason for the internal interface to be different. Since we only have
one window-based driver anyway, clean up the core code by just moving
the DOMAIN_ATTR_WINDOWS handling directly into the PAMU driver.
Signed-off-by: Robin Murphy
---
Just a cleanup opportunity I spotted whilst poking around in the area.
drivers/iommu/fsl_pamu_domain.c | 20
drivers/iommu/iommu.c | 20
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index f089136e9c3f..f83965ee3095 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -818,6 +818,7 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain
*domain,
enum iommu_attr attr_type, void *data)
{
struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
+ u32 *count;
int ret = 0;
switch (attr_type) {
@@ -829,6 +830,15 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain
*domain,
break;
case DOMAIN_ATTR_FSL_PAMU_ENABLE:
ret = configure_domain_dma_state(dma_domain, *(int *)data);
+ break;
+ case DOMAIN_ATTR_WINDOWS:
+ count = data;
+
+ if (domain->ops->domain_set_windows != NULL)
+ ret = domain->ops->domain_set_windows(domain, *count);
+ else
+ ret = -ENODEV;
+
break;
default:
pr_debug("Unsupported attribute type\n");
@@ -843,6 +853,7 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain
*domain,
enum iommu_attr attr_type, void *data)
{
struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
+ u32 *count;
int ret = 0;
switch (attr_type) {
@@ -855,6 +866,15 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain
*domain,
break;
case DOMAIN_ATTR_FSL_PAMUV1:
*(int *)data = DOMAIN_ATTR_FSL_PAMUV1;
+ break;
+ case DOMAIN_ATTR_WINDOWS:
+ count = data;
+
+ if (domain->ops->domain_get_windows != NULL)
+ *count = domain->ops->domain_get_windows(domain);
+ else
+ ret = -ENODEV;
+
break;
default:
pr_debug("Unsupported attribute type\n");
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 8c15c5980299..2faec6aa73c4 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1796,7 +1796,6 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
struct iommu_domain_geometry *geometry;
bool *paging;
int ret = 0;
- u32 *count;
switch (attr) {
case DOMAIN_ATTR_GEOMETRY:
@@ -1807,15 +1806,6 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
case DOMAIN_ATTR_PAGING:
paging = data;
*paging = (domain->pgsize_bitmap != 0UL);
- break;
- case DOMAIN_ATTR_WINDOWS:
- count = data;
-
- if (domain->ops->domain_get_windows != NULL)
- *count = domain->ops->domain_get_windows(domain);
- else
- ret = -ENODEV;
-
break;
default:
if (!domain->ops->domain_get_attr)
@@ -1832,18 +1822,8 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
{
int ret = 0;
- u32 *count;
switch (attr) {
- case DOMAIN_ATTR_WINDOWS:
- count = data;
-
- if (domain->ops->domain_set_windows != NULL)
- ret = domain->ops->domain_set_windows(domain, *count);
- else
- ret = -ENODEV;
-
- break;
default:
if (domain->ops->domain_set_attr == NULL)
return -EINVAL;
--
2.19.0.dirty
[PATCH 2/2] iommu: Remove .domain_{get,set}_windows
Since these are trivially handled by the .domain_{get,set}_attr
callbacks when relevant, we can streamline struct iommu_ops for
everyone.
Signed-off-by: Robin Murphy
---
drivers/iommu/fsl_pamu_domain.c | 125 +---
include/linux/iommu.h | 6 --
2 files changed, 51 insertions(+), 80 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index f83965ee3095..a906ce8cf83b 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -814,11 +814,59 @@ static int configure_domain_dma_state(struct
fsl_dma_domain *dma_domain, bool en
return 0;
}
+static int fsl_pamu_set_windows(struct iommu_domain *domain, u32 w_count)
+{
+ struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(_domain->domain_lock, flags);
+ /* Ensure domain is inactive i.e. DMA should be disabled for the domain
*/
+ if (dma_domain->enabled) {
+ pr_debug("Can't set geometry attributes as domain is active\n");
+ spin_unlock_irqrestore(_domain->domain_lock, flags);
+ return -EBUSY;
+ }
+
+ /* Ensure that the geometry has been set for the domain */
+ if (!dma_domain->geom_size) {
+ pr_debug("Please configure geometry before setting the number
of windows\n");
+ spin_unlock_irqrestore(_domain->domain_lock, flags);
+ return -EINVAL;
+ }
+
+ /*
+* Ensure we have valid window count i.e. it should be less than
+* maximum permissible limit and should be a power of two.
+*/
+ if (w_count > pamu_get_max_subwin_cnt() || !is_power_of_2(w_count)) {
+ pr_debug("Invalid window count\n");
+ spin_unlock_irqrestore(_domain->domain_lock, flags);
+ return -EINVAL;
+ }
+
+ ret = pamu_set_domain_geometry(dma_domain, >geometry,
+ w_count > 1 ? w_count : 0);
+ if (!ret) {
+ kfree(dma_domain->win_arr);
+ dma_domain->win_arr = kcalloc(w_count,
+ sizeof(*dma_domain->win_arr),
+ GFP_ATOMIC);
+ if (!dma_domain->win_arr) {
+ spin_unlock_irqrestore(_domain->domain_lock, flags);
+ return -ENOMEM;
+ }
+ dma_domain->win_cnt = w_count;
+ }
+ spin_unlock_irqrestore(_domain->domain_lock, flags);
+
+ return ret;
+}
+
static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
enum iommu_attr attr_type, void *data)
{
struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
- u32 *count;
int ret = 0;
switch (attr_type) {
@@ -832,13 +880,7 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain
*domain,
ret = configure_domain_dma_state(dma_domain, *(int *)data);
break;
case DOMAIN_ATTR_WINDOWS:
- count = data;
-
- if (domain->ops->domain_set_windows != NULL)
- ret = domain->ops->domain_set_windows(domain, *count);
- else
- ret = -ENODEV;
-
+ ret = fsl_pamu_set_windows(domain, *(u32 *)data);
break;
default:
pr_debug("Unsupported attribute type\n");
@@ -853,7 +895,6 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain
*domain,
enum iommu_attr attr_type, void *data)
{
struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
- u32 *count;
int ret = 0;
switch (attr_type) {
@@ -868,13 +909,7 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain
*domain,
*(int *)data = DOMAIN_ATTR_FSL_PAMUV1;
break;
case DOMAIN_ATTR_WINDOWS:
- count = data;
-
- if (domain->ops->domain_get_windows != NULL)
- *count = domain->ops->domain_get_windows(domain);
- else
- ret = -ENODEV;
-
+ *(u32 *)data = dma_domain->win_cnt;
break;
default:
pr_debug("Unsupported attribute type\n");
@@ -1014,62 +1049,6 @@ static void fsl_pamu_remove_device(struct device *dev)
iommu_group_remove_device(dev);
}
-static int fsl_pamu_set_windows(struct iommu_domain *domain, u32 w_count)
-{
- struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(_domain->domain_lock, flags);
- /* Ensure domain is inactive i.e. DMA should be disabled for the domain
*/
- if (dma_domain->enabled) {
- pr_debug("Can't set geometry attributes as
How to define some additional KBUILD_CFLAGS after building include/generated/asm-offsets.h ?
I'm trying to implement TLS based stack protector in the Linux Kernel.
For that I need to give to GCC the offset at which it will find the
canary (register r2 is pointing to the current task struct).
I have been able to do it with the below patch, but it only works when
include/generated/asm-offsets.h already exists from the start of the build.
Is there a way to evaluate CANARY_OFFSET and add the stack-protector
flags to KBUILD_FLAGS only after include/generated/asm-offsets.h is built ?
Or another way of add -mstack-protector-guard-offset=offsetof(struct
task_struct, stack_canary) ?
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 89cf15566c4e..b25483946921 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -89,6 +89,9 @@ int main(void)
DEFINE(THREAD_INFO_GAP, _ALIGN_UP(sizeof(struct thread_info), 16));
OFFSET(KSP_LIMIT, thread_struct, ksp_limit);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_STACKPROTECTOR
+ DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct,
stack_canary));
+#endif
#ifdef CONFIG_LIVEPATCH
OFFSET(TI_livepatch_sp, thread_info, livepatch_sp);
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index e58c3f467db5..051b907b5c02 100644
[root@pc16082vm linux-powerpc]# git diff
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 748e34e81a03..7b5a23a8afe8 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -113,7 +113,8 @@ KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
endif
ifdef CONFIG_STACKPROTECTOR
-KBUILD_CFLAGS += -mstack-protector-guard=global
+CANARY_OFFSET := $(shell awk '{if ($$2 == "TSK_STACK_CANARY") print
$$3;}' include/generated/asm-offsets.h)
+KBUILD_CFLAGS += -mstack-protector-guard=tls
-mstack-protector-guard-reg=r2
-mstack-protector-guard-offset=$(CANARY_OFFSET)
endif
LDFLAGS_vmlinux-y := -Bstatic
Thanks
Christophe
[RFC PATCH 3/4] powerpc/pseries: Introduce helpers to change the DTL enable mask
In a subsequent patch, we want to be able to change the DTL enable mask
globally for all cpus. This conflicts with the current debugfs interface
that provides access to the DTL buffer contents.
To ensure consistent behavior, we introduce helpers to change the DTL
enable mask on either a specific cpu, or globally for all cpus. Setting
the DTL enable mask globally prevents changes to cpu-specific DTL enable
mask, and vice versa. We also introduce 'dtl_mask' so that when the DTL
enable mask is changed globally, new cpus also honor that.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/lppaca.h | 4 ++
arch/powerpc/platforms/pseries/dtl.c | 5 +-
arch/powerpc/platforms/pseries/lpar.c | 64 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
4 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index 2c7e31187726..144862f86392 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -165,6 +165,10 @@ struct dtl_entry {
#define DTL_LOG_FAULT 0x4
#define DTL_LOG_ALL(DTL_LOG_CEDE | DTL_LOG_PREEMPT | DTL_LOG_FAULT)
+extern u8 dtl_mask;
+int set_dtl_mask(int cpu, int mask);
+void reset_dtl_mask(int cpu);
+
extern struct kmem_cache *dtl_cache;
/*
diff --git a/arch/powerpc/platforms/pseries/dtl.c
b/arch/powerpc/platforms/pseries/dtl.c
index fe333c2525fb..3b98fc19c53f 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -104,7 +104,8 @@ static int dtl_start(struct dtl *dtl)
dtlr->write_ptr = dtl->buf;
/* enable event logging */
- lppaca_of(dtl->cpu).dtl_enable_mask |= dtl_event_mask;
+ if (set_dtl_mask(dtl->cpu, dtl_event_mask))
+ return -EBUSY;
dtl_consumer = consume_dtle;
atomic_inc(_count);
@@ -121,7 +122,7 @@ static void dtl_stop(struct dtl *dtl)
dtlr->buf = NULL;
/* restore dtl_enable_mask */
- lppaca_of(dtl->cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
+ reset_dtl_mask(dtl->cpu);
if (atomic_dec_and_test(_count))
dtl_consumer = NULL;
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index dd024a192512..6563e7a782a3 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -58,12 +58,74 @@
#define HBR_AVPN 0x0200UL
#define HBR_ANDCOND0x0100UL
+u8 dtl_mask = DTL_LOG_PREEMPT;
+static u8 dtl_mask_global_refctr, dtl_mask_percpu_inuse;
+static DEFINE_MUTEX(dtl_mask_mutex);
/* in hvCall.S */
EXPORT_SYMBOL(plpar_hcall);
EXPORT_SYMBOL(plpar_hcall9);
EXPORT_SYMBOL(plpar_hcall_norets);
+int set_dtl_mask(int cpu, int mask)
+{
+ int rc = 0;
+
+ mutex_lock(_mask_mutex);
+
+ if ((cpu == -1 && dtl_mask_percpu_inuse) ||
+ (cpu >= 0 && dtl_mask_global_refctr)) {
+ rc = -1;
+ goto out;
+ }
+
+ if (cpu >= 0) {
+ dtl_mask_percpu_inuse++;
+ lppaca_of(cpu).dtl_enable_mask = mask;
+ goto out;
+ }
+
+ if (dtl_mask_global_refctr && mask != dtl_mask) {
+ rc = -1;
+ goto out;
+ }
+
+ if (!dtl_mask_global_refctr) {
+ dtl_mask = mask;
+ for_each_present_cpu(cpu)
+ lppaca_of(cpu).dtl_enable_mask = mask;
+ }
+
+ dtl_mask_global_refctr++;
+
+out:
+ mutex_unlock(_mask_mutex);
+
+ return rc;
+}
+
+void reset_dtl_mask(int cpu)
+{
+ mutex_lock(_mask_mutex);
+
+ if (cpu >= 0) {
+ dtl_mask_percpu_inuse--;
+ lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
+ goto out;
+ }
+
+ dtl_mask_global_refctr--;
+
+ if (!dtl_mask_global_refctr) {
+ dtl_mask = DTL_LOG_PREEMPT;
+ for_each_present_cpu(cpu)
+ lppaca_of(cpu).dtl_enable_mask = dtl_mask;
+ }
+
+out:
+ mutex_unlock(_mask_mutex);
+}
+
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
@@ -125,7 +187,7 @@ void vpa_init(int cpu)
pr_err("WARNING: DTL registration of cpu %d (hw %d) "
"failed with %ld\n", smp_processor_id(),
hwcpu, ret);
- lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
+ lppaca_of(cpu).dtl_enable_mask = dtl_mask;
}
}
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index a48cb9757be2..285a35f32d3d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -293,7 +293,7 @@ static int alloc_dispatch_logs(void)
pr_err("WARNING: DTL registration of cpu %d (hw %d) failed "
"with %d\n",
Re: [RFC PATCH 03/29] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, 5 Sep 2018 18:59:18 +0300
Mike Rapoport wrote:
> All architecures use memblock for early memory management. There is no need
> for the CONFIG_HAVE_MEMBLOCK configuration option.
>
> Signed-off-by: Mike Rapoport
Hi Mike,
A minor editing issue in here that is stopping boot on arm64 platforms with
latest
version of the mm tree.
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 76c83c1..bd841bb 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1115,13 +1115,11 @@ int __init early_init_dt_scan_chosen(unsigned long
> node, const char *uname,
> return 1;
> }
>
> -#ifdef CONFIG_HAVE_MEMBLOCK
> #ifndef MIN_MEMBLOCK_ADDR
> #define MIN_MEMBLOCK_ADDR__pa(PAGE_OFFSET)
> #endif
> #ifndef MAX_MEMBLOCK_ADDR
> #define MAX_MEMBLOCK_ADDR((phys_addr_t)~0)
> -#endif
This isn't the right #endif. It is matching with the #ifndef MAX_MEMBLOCK_ADDR
not the intented #ifdef CONFIG_HAVE_MEMBLOCK.
Now I haven't chased through the exact reason this is causing my acpi
arm64 system not to boot on the basis it is obviously miss-matched anyway
and I'm inherently lazy. It's resulting in stubs replacing the following weak
functions.
early_init_dt_add_memory_arch
(this is defined elsewhere for some architectures but not arm)
early_init_dt_mark_hotplug_memory_arch
(there is only one definition of this in the kernel so it doesn't
need to be weak or in the header etc).
early_init_dt_reserve_memory_arch
(defined on mips but nothing else)
Taking out the right endif also lets you drop an #else removing some stub
functions further down in here.
Nice cleanup in general btw.
Thanks,
Jonathan
>
> void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> {
[RFC PATCH 4/4] powerpc/pseries: Introduce dtl_entry tracepoint
This tracepoint provides access to the fields of each DTL entry in the
Dispatch Trace Log buffer, and is hit when processing the DTL buffer for
accounting stolen time. As such, this tracepoint is only available when
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is enabled.
Apart from making the DTL entries available for processing through the
usual trace interface, this tracepoint also adds a new field 'distance'
to each DTL entry, enabling enhanced statistics around the vcpu dispatch
behavior of the hypervisor.
For Shared Processor LPARs, the POWER Hypervisor maintains a relatively
static mapping of LPAR vcpus to physical processor cores and tries to
always dispatch vcpus on their associated physical processor core. The
LPAR can discover this through the H_VPHN(flags=1) hcall to obtain the
associativity of the LPAR vcpus.
However, under certain scenarios, vcpus may be dispatched on a different
processor core. The actual physical processor number on which a certain
vcpu is dispatched is available to the LPAR in the 'processor_id' field
of each DTL entry. The LPAR can then discover the associativity of that
physical processor through the H_VPHN(flags=2) hcall. This can then be
compared to the home node associativity for that specific vcpu to
determine if the vcpu was dispatched on the same core or not. If the
vcpu was not dispatched on the home node, it is possible to determine if
the vcpu was dispatched in a different chip, socket or drawer.
The tracepoint field 'distance' encodes this information. If distance is
0, then the vcpu was dispatched on its home node. If not, increasing
values of 'distance' indicate a dispatch on a different core in the same
chip, different chip in a DCM, different socket or a different drawer.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/trace.h | 53 ++
arch/powerpc/kernel/time.c | 9 +++
arch/powerpc/mm/numa.c | 94 ++--
3 files changed, 150 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h
index d018e8602694..27ccb2c8afc3 100644
--- a/arch/powerpc/include/asm/trace.h
+++ b/arch/powerpc/include/asm/trace.h
@@ -101,6 +101,59 @@ TRACE_EVENT_FN_COND(hcall_exit,
hcall_tracepoint_regfunc, hcall_tracepoint_unregfunc
);
+
+extern int dtl_entry_tracepoint_regfunc(void);
+extern void dtl_entry_tracepoint_unregfunc(void);
+extern u8 compute_dispatch_distance(unsigned int pcpu);
+
+TRACE_EVENT_FN(dtl_entry,
+
+ TP_PROTO(u8 dispatch_reason, u8 preempt_reason, u16 processor_id,
+ u32 enqueue_to_dispatch_time, u32 ready_to_enqueue_time,
+ u32 waiting_to_ready_time, u64 timebase, u64 fault_addr,
+ u64 srr0, u64 srr1),
+
+ TP_ARGS(dispatch_reason, preempt_reason, processor_id,
+ enqueue_to_dispatch_time, ready_to_enqueue_time,
+ waiting_to_ready_time, timebase, fault_addr,
+ srr0, srr1),
+
+ TP_STRUCT__entry(
+ __field(u8, dispatch_reason)
+ __field(u8, preempt_reason)
+ __field(u16, processor_id)
+ __field(u32, enqueue_to_dispatch_time)
+ __field(u32, ready_to_enqueue_time)
+ __field(u32, waiting_to_ready_time)
+ __field(u64, timebase)
+ __field(u64, fault_addr)
+ __field(u64, srr0)
+ __field(u64, srr1)
+ __field(u8, distance)
+ ),
+
+ TP_fast_assign(
+ __entry->dispatch_reason = dispatch_reason;
+ __entry->preempt_reason = preempt_reason;
+ __entry->processor_id = processor_id;
+ __entry->enqueue_to_dispatch_time = enqueue_to_dispatch_time;
+ __entry->ready_to_enqueue_time = ready_to_enqueue_time;
+ __entry->waiting_to_ready_time = waiting_to_ready_time;
+ __entry->timebase = timebase;
+ __entry->fault_addr = fault_addr;
+ __entry->srr0 = srr0;
+ __entry->srr1 = srr1;
+ __entry->distance = compute_dispatch_distance(processor_id);
+ ),
+
+ TP_printk("dispatch_reason=%u preempt_reason=%u processor_id=%u
enq_to_disp=%u ready_to_enq=%u wait_to_ready=%u tb=%llu fault_addr=0x%llx
srr0=0x%llx srr1=0x%llx distance=%u",
+ __entry->dispatch_reason, __entry->preempt_reason,
__entry->processor_id,
+ __entry->enqueue_to_dispatch_time,
__entry->ready_to_enqueue_time,
+ __entry->waiting_to_ready_time, __entry->timebase,
__entry->fault_addr,
+ __entry->srr0, __entry->srr1, __entry->distance),
+
+ dtl_entry_tracepoint_regfunc, dtl_entry_tracepoint_unregfunc
+);
#endif
#ifdef CONFIG_PPC_POWERNV
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 70f145e02487..94802fc22521 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@
[RFC PATCH 2/4] powerpc/pseries: Do not save the previous DTL mask value
When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is enabled, we always initialize
DTL enable mask to DTL_LOG_PREEMPT (0x2). There are no other places
where the mask is changed. As such, when reading the DTL log buffer
through debugfs, there is no need to save and restore the previous mask
value.
We don't need to save and restore the earlier mask value if
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not enabled. So, remove the field
from the structure as well.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/platforms/pseries/dtl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dtl.c
b/arch/powerpc/platforms/pseries/dtl.c
index e0421aa6eafa..fe333c2525fb 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -55,7 +55,6 @@ struct dtl_ring {
struct dtl_entry *write_ptr;
struct dtl_entry *buf;
struct dtl_entry *buf_end;
- u8 saved_dtl_mask;
};
static DEFINE_PER_CPU(struct dtl_ring, dtl_rings);
@@ -105,7 +104,6 @@ static int dtl_start(struct dtl *dtl)
dtlr->write_ptr = dtl->buf;
/* enable event logging */
- dtlr->saved_dtl_mask = lppaca_of(dtl->cpu).dtl_enable_mask;
lppaca_of(dtl->cpu).dtl_enable_mask |= dtl_event_mask;
dtl_consumer = consume_dtle;
@@ -123,7 +121,7 @@ static void dtl_stop(struct dtl *dtl)
dtlr->buf = NULL;
/* restore dtl_enable_mask */
- lppaca_of(dtl->cpu).dtl_enable_mask = dtlr->saved_dtl_mask;
+ lppaca_of(dtl->cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
if (atomic_dec_and_test(_count))
dtl_consumer = NULL;
--
2.18.0
[RFC PATCH 1/4] powerpc/pseries: Use macros for referring to the DTL enable mask
Introduce macros to encode the DTL enable mask fields and use those
instead of hardcoding numbers.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/lppaca.h | 11 +++
arch/powerpc/platforms/pseries/dtl.c | 8 +---
arch/powerpc/platforms/pseries/lpar.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index 7c23ce8a5a4c..2c7e31187726 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -154,6 +154,17 @@ struct dtl_entry {
#define DISPATCH_LOG_BYTES 4096/* bytes per cpu */
#define N_DISPATCH_LOG (DISPATCH_LOG_BYTES / sizeof(struct dtl_entry))
+/*
+ * Dispatch trace log event enable mask:
+ * 0x1: voluntary virtual processor waits
+ * 0x2: time-slice preempts
+ * 0x4: virtual partition memory page faults
+ */
+#define DTL_LOG_CEDE 0x1
+#define DTL_LOG_PREEMPT0x2
+#define DTL_LOG_FAULT 0x4
+#define DTL_LOG_ALL(DTL_LOG_CEDE | DTL_LOG_PREEMPT | DTL_LOG_FAULT)
+
extern struct kmem_cache *dtl_cache;
/*
diff --git a/arch/powerpc/platforms/pseries/dtl.c
b/arch/powerpc/platforms/pseries/dtl.c
index 18014cdeb590..e0421aa6eafa 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -40,13 +40,7 @@ struct dtl {
};
static DEFINE_PER_CPU(struct dtl, cpu_dtl);
-/*
- * Dispatch trace log event mask:
- * 0x7: 0x1: voluntary virtual processor waits
- * 0x2: time-slice preempts
- * 0x4: virtual partition memory page faults
- */
-static u8 dtl_event_mask = 0x7;
+static u8 dtl_event_mask = DTL_LOG_ALL;
/*
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index d3992ced0782..dd024a192512 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -125,7 +125,7 @@ void vpa_init(int cpu)
pr_err("WARNING: DTL registration of cpu %d (hw %d) "
"failed with %ld\n", smp_processor_id(),
hwcpu, ret);
- lppaca_of(cpu).dtl_enable_mask = 2;
+ lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
}
}
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index ba1791fd3234..a48cb9757be2 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -293,7 +293,7 @@ static int alloc_dispatch_logs(void)
pr_err("WARNING: DTL registration of cpu %d (hw %d) failed "
"with %d\n", smp_processor_id(),
hard_smp_processor_id(), ret);
- get_paca()->lppaca_ptr->dtl_enable_mask = 2;
+ get_paca()->lppaca_ptr->dtl_enable_mask = DTL_LOG_PREEMPT;
return 0;
}
--
2.18.0
[RFC PATCH 0/4] Add a tracepoint for DTL entries
Add a tracepoint for the DTL entries to enable processing the DTL entries via the kernel tracing infrastructure. In addition to that, the tracpoint also exposes where a vcpu was dispatched in a SPLPAR environment, relative to the Power Hypervisor's idea of that vcpu's home node. This is working fine for me, so posting this out to get some early feedback. The one aspect I need to look into is in terms of updating the pcpu associativity masks on appropriate events. - Naveen Naveen N. Rao (4): powerpc/pseries: Use macros for referring to the DTL enable mask powerpc/pseries: Do not save the previous DTL mask value powerpc/pseries: Introduce helpers to change the DTL enable mask powerpc/pseries: Introduce dtl_entry tracepoint arch/powerpc/include/asm/lppaca.h | 15 arch/powerpc/include/asm/trace.h | 53 +++ arch/powerpc/kernel/time.c | 9 +++ arch/powerpc/mm/numa.c | 94 -- arch/powerpc/platforms/pseries/dtl.c | 15 ++-- arch/powerpc/platforms/pseries/lpar.c | 64 +- arch/powerpc/platforms/pseries/setup.c | 2 +- 7 files changed, 233 insertions(+), 19 deletions(-) -- 2.18.0
Re: [PATCH v2 4/5] powerpc: Fix duplicate const clang warning in user access code
On Sat, 15 Sep 2018 at 03:27, Nick Desaulniers wrote: > > On Thu, Sep 13, 2018 at 9:07 PM Joel Stanley wrote: > > > > From: Anton Blanchard > > > > This re-applies b91c1e3e7a6f which was reverted in f2ca80905929 > > d466f6c5cac1 f84ed59a612d (powerpc/sparse: Constify the address pointer > > ..."). > > > > We see a large number of duplicate const errors in the user access > > code when building with llvm/clang: > > > > include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration > > specifier > > [-Wduplicate-decl-specifier] > > ret = __get_user(c, uaddr); > > > > The problem is we are doing const __typeof__(*(ptr)), which will hit the > > warning if ptr is marked const. > > > > Removing const does not seem to have any effect on GCC code generation. > > I wouldn't expect it to for a local variable with such localized > usage. I myself am quite liberal in applying `const` to everything, > so I will try to fix this in Clang as well, but this should silence > the warning for users of older versions of Clang and results in no > functional change. > Reviewed-by: Nick Desaulniers Nick has written a clang patch that suppresses the warning in the same way as GCC. Assuming it gets merged, as we depend on clang-8 we could chose to not merge the kernel patch. https://reviews.llvm.org/D52248 Cheers, Joel
Re: [PATCH v1 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
Am 19.09.18 um 03:22 schrieb Balbir Singh: > On Tue, Sep 18, 2018 at 01:48:16PM +0200, David Hildenbrand wrote: >> Reading through the code and studying how mem_hotplug_lock is to be used, >> I noticed that there are two places where we can end up calling >> device_online()/device_offline() - online_pages()/offline_pages() without >> the mem_hotplug_lock. And there are other places where we call >> device_online()/device_offline() without the device_hotplug_lock. >> >> While e.g. >> echo "online" > /sys/devices/system/memory/memory9/state >> is fine, e.g. >> echo 1 > /sys/devices/system/memory/memory9/online >> Will not take the mem_hotplug_lock. However the device_lock() and >> device_hotplug_lock. >> >> E.g. via memory_probe_store(), we can end up calling >> add_memory()->online_pages() without the device_hotplug_lock. So we can >> have concurrent callers in online_pages(). We e.g. touch in online_pages() >> basically unprotected zone->present_pages then. >> >> Looks like there is a longer history to that (see Patch #2 for details), >> and fixing it to work the way it was intended is not really possible. We >> would e.g. have to take the mem_hotplug_lock in device/base/core.c, which >> sounds wrong. >> >> Summary: We had a lock inversion on mem_hotplug_lock and device_lock(). >> More details can be found in patch 3 and patch 6. >> >> I propose the general rules (documentation added in patch 6): >> >> 1. add_memory/add_memory_resource() must only be called with >>device_hotplug_lock. >> 2. remove_memory() must only be called with device_hotplug_lock. This is >>already documented and holds for all callers. >> 3. device_online()/device_offline() must only be called with >>device_hotplug_lock. This is already documented and true for now in core >>code. Other callers (related to memory hotplug) have to be fixed up. >> 4. mem_hotplug_lock is taken inside of add_memory/remove_memory/ >>online_pages/offline_pages. >> >> To me, this looks way cleaner than what we have right now (and easier to >> verify). And looking at the documentation of remove_memory, using >> lock_device_hotplug also for add_memory() feels natural. >> > > That seems reasonable, but also implies that device_online() would hold > back add/remove memory, could you please also document what mode > read/write the locks need to be held? For example can the device_hotplug_lock > be held in read mode while add/remove memory via (mem_hotplug_lock) is held > in write mode? device_hotplug_lock is an ordinary mutex. So no option there. Only mem_hotplug_lock is a per CPU RW mutex. And as of now it only exists to not require get_online_mems()/put_online_mems() to take the device_hotplug_lock. Which is perfectly valid, because these users only care about memory (not any other devices) not suddenly vanish. And that RW lock makes things fast. Any modifications (online/offline/add/remove) require the mem_hotplug_lock in write. I can add some more details to documentation in patch #6. "... we should always hold the mem_hotplug_lock (via mem_hotplug_begin/mem_hotplug_done) in write mode to serialize memory hotplug" ..." "In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read mode allows for a quite efficient get_online_mems/put_online_mems implementation, so code accessing memory can protect from that memory vanishing." Would that work for you? Thanks! > > Balbir Singh. > > -- Thanks, David / dhildenb
Re: [PATCH] lib/xz: Fix powerpc build with KERNEL_XZ
Le 19/09/2018 à 08:44, Oliver a écrit :
On Wed, Sep 19, 2018 at 3:52 PM, Christophe LEROY
wrote:
Le 19/09/2018 à 01:07, Joel Stanley a écrit :
This partially reverts faa16bc404d72a5 ("lib: Use existing define with
polynomial").
The cleanup added a dependency on include/linux, which broke the PowerPC
boot wrapper/decompresser when KERNEL_XZ is enabled:
BOOTCC arch/powerpc/boot/decompress.o
In file included from
arch/powerpc/boot/../../../lib/decompress_unxz.c:233,
from arch/powerpc/boot/decompress.c:42:
arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error:
linux/crc32poly.h: No such file or directory
#include
^~~
The powerpc decompressor is a hairy corner of the kernel. Even while
building
a 64-bit kernel it needs to build a 32-bit binary and therefore avoid
including
files from include/linux.
Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
Signed-off-by: Joel Stanley
---
We need to clean up the powerpc boot decompresser but that work will be
more involved than we would include in a late -rc. Please consider
merging this fix for 4.19. Thanks!
lib/xz/xz_crc32.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/xz/xz_crc32.c b/lib/xz/xz_crc32.c
index 25a5d87e2e4c..34532d14fd4c 100644
--- a/lib/xz/xz_crc32.c
+++ b/lib/xz/xz_crc32.c
@@ -15,7 +15,6 @@
* but they are bigger and use more memory for the lookup table.
*/
-#include
#include "xz_private.h"
/*
@@ -30,7 +29,7 @@ STATIC_RW_DATA uint32_t xz_crc32_table[256];
XZ_EXTERN void xz_crc32_init(void)
{
- const uint32_t poly = CRC32_POLY_LE;
+ const uint32_t poly = 0xEDB88320;
Maybe avoid capital letters ?
What about adding something like the following in xz_private.h instead:
#define CRC32_POLY_LE 0xedb88320
The problem is that it's pulling in linux/crc32poly.h. To support old
systems with a 32bit Open Firmware we boot wrapper we build the boot
wrapper as a 32bit ELF even for a 64 bit kernel. The headers generated
by Kbuild are only valid for the 64bit kernel so we have to avoid
pulling them into the boot wrapper.
Yes I understood, hence my proposal to redefine CRC32_POLY_LE in
xz_private.h instead of including linux/crc32poly.h
It avoids modifying the C code.
Christophe
Christophe
uint32_t i;
uint32_t j;
Re: [PATCH] lib/xz: Fix powerpc build with KERNEL_XZ
On Wed, Sep 19, 2018 at 3:52 PM, Christophe LEROY
wrote:
>
>
> Le 19/09/2018 à 01:07, Joel Stanley a écrit :
>>
>> This partially reverts faa16bc404d72a5 ("lib: Use existing define with
>> polynomial").
>>
>> The cleanup added a dependency on include/linux, which broke the PowerPC
>> boot wrapper/decompresser when KERNEL_XZ is enabled:
>>
>>BOOTCC arch/powerpc/boot/decompress.o
>> In file included from
>> arch/powerpc/boot/../../../lib/decompress_unxz.c:233,
>> from arch/powerpc/boot/decompress.c:42:
>> arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error:
>> linux/crc32poly.h: No such file or directory
>>#include
>> ^~~
>>
>> The powerpc decompressor is a hairy corner of the kernel. Even while
>> building
>> a 64-bit kernel it needs to build a 32-bit binary and therefore avoid
>> including
>> files from include/linux.
>>
>> Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
>> Signed-off-by: Joel Stanley
>> ---
>> We need to clean up the powerpc boot decompresser but that work will be
>> more involved than we would include in a late -rc. Please consider
>> merging this fix for 4.19. Thanks!
>>
>> lib/xz/xz_crc32.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/lib/xz/xz_crc32.c b/lib/xz/xz_crc32.c
>> index 25a5d87e2e4c..34532d14fd4c 100644
>> --- a/lib/xz/xz_crc32.c
>> +++ b/lib/xz/xz_crc32.c
>> @@ -15,7 +15,6 @@
>>* but they are bigger and use more memory for the lookup table.
>>*/
>> -#include
>> #include "xz_private.h"
>> /*
>> @@ -30,7 +29,7 @@ STATIC_RW_DATA uint32_t xz_crc32_table[256];
>> XZ_EXTERN void xz_crc32_init(void)
>> {
>> - const uint32_t poly = CRC32_POLY_LE;
>> + const uint32_t poly = 0xEDB88320;
>
>
> Maybe avoid capital letters ?
>
> What about adding something like the following in xz_private.h instead:
>
> #define CRC32_POLY_LE 0xedb88320
The problem is that it's pulling in linux/crc32poly.h. To support old
systems with a 32bit Open Firmware we boot wrapper we build the boot
wrapper as a 32bit ELF even for a 64 bit kernel. The headers generated
by Kbuild are only valid for the 64bit kernel so we have to avoid
pulling them into the boot wrapper.
> Christophe
>
>> uint32_t i;
>> uint32_t j;
>>
>
Re: [PATCH] lib/xz: Fix powerpc build with KERNEL_XZ
On Wed, 19 Sep 2018 at 01:08, Joel Stanley wrote:
>
> This partially reverts faa16bc404d72a5 ("lib: Use existing define with
> polynomial").
>
> The cleanup added a dependency on include/linux, which broke the PowerPC
> boot wrapper/decompresser when KERNEL_XZ is enabled:
>
> BOOTCC arch/powerpc/boot/decompress.o
> In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233,
> from arch/powerpc/boot/decompress.c:42:
> arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error:
> linux/crc32poly.h: No such file or directory
> #include
>^~~
>
> The powerpc decompressor is a hairy corner of the kernel. Even while building
> a 64-bit kernel it needs to build a 32-bit binary and therefore avoid
> including
> files from include/linux.
I fixed the build error here:
https://lkml.org/lkml/2018/8/29/179
If you choose to remove any includes from /linux, then go ahead but
please use original reported-by :)
Best regards,
Krzysztof
>
> Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
> Signed-off-by: Joel Stanley
> ---
> We need to clean up the powerpc boot decompresser but that work will be
> more involved than we would include in a late -rc. Please consider
> merging this fix for 4.19. Thanks!
>
> lib/xz/xz_crc32.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/xz/xz_crc32.c b/lib/xz/xz_crc32.c
> index 25a5d87e2e4c..34532d14fd4c 100644
> --- a/lib/xz/xz_crc32.c
> +++ b/lib/xz/xz_crc32.c
> @@ -15,7 +15,6 @@
> * but they are bigger and use more memory for the lookup table.
> */
>
> -#include
> #include "xz_private.h"
>
> /*
> @@ -30,7 +29,7 @@ STATIC_RW_DATA uint32_t xz_crc32_table[256];
>
> XZ_EXTERN void xz_crc32_init(void)
> {
> - const uint32_t poly = CRC32_POLY_LE;
> + const uint32_t poly = 0xEDB88320;
>
> uint32_t i;
> uint32_t j;
> --
> 2.17.1
>
RE: [PATCH] powerpc/mpc85xx: fix issues in clock node
Hi Scott,
What you said makes sense well. I will resend the patch.
Thanks,
Andy
> -Original Message-
> From: Scott Wood
> Sent: 2018年9月19日 6:24
> To: Andy Tang
> Cc: robh...@kernel.org; mark.rutl...@arm.com;
> b...@kernel.crashing.org; devicet...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/mpc85xx: fix issues in clock node
>
> On Tue, 2018-09-11 at 10:12 +0800, andy.t...@nxp.com wrote:
> > From: Yuantian Tang
> >
> > The compatible string is not correct in the clock node.
> > The clocks property refers to the wrong node too.
> > This patch is to fix them.
> >
> > Signed-off-by: Tang Yuantian
> > ---
> > arch/powerpc/boot/dts/fsl/t1023si-post.dtsi |8
> > 1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> > b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> > index 4908af5..763caf4 100644
> > --- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
> > @@ -348,7 +348,7 @@
> > mux0: mux0@0 {
> > #clock-cells = <0>;
> > reg = <0x0 4>;
> > - compatible = "fsl,core-mux-clock";
> > + compatible = "fsl,qoriq-core-mux-2.0";
> > clocks = < 0>, < 1>;
> > clock-names = "pll0_0", "pll0_1";
> > clock-output-names = "cmux0";
> > @@ -356,9 +356,9 @@
> > mux1: mux1@20 {
> > #clock-cells = <0>;
> > reg = <0x20 4>;
> > - compatible = "fsl,core-mux-clock";
> > - clocks = < 0>, < 1>;
> > - clock-names = "pll0_0", "pll0_1";
> > + compatible = "fsl,qoriq-core-mux-2.0";
> > + clocks = < 0>, < 1>;
> > + clock-names = "pll1_0", "pll1_1";
> > clock-output-names = "cmux1";
> > };
> > };
>
> These are the legacy nodes. Why not just remove them instead of fixing
> them?
> Now that the cpufreq driver is fixed we could get rid of the legacy nodes
> for all the chips.
>
> -Scott
