* Re: [PATCH v2 1/2] sched: move stack_canary field at the top of task_struct
From: Michael Ellerman @ 2018-09-19 23:54 UTC (permalink / raw)
To: Christophe LEROY, Peter Zijlstra
Cc: Benjamin Herrenschmidt, Paul Mackerras, Ingo Molnar, segher,
linux-kernel, linuxppc-dev
In-Reply-To: <f6a36d25-ce19-5d56-69d9-198215a7b9e1@c-s.fr>
Christophe LEROY <christophe.leroy@c-s.fr> writes:
> Le 19/09/2018 =C3=A0 13:58, Peter Zijlstra a =C3=A9crit=C2=A0:
>> On Wed, Sep 19, 2018 at 11:14:43AM +0000, 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.
>>=20
>> 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=
=20
> 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
^ permalink raw reply
* [PATCH -next] tty: serial: remove set but not used variable 'error'
From: YueHaibing @ 2018-09-20 1:59 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman
Cc: YueHaibing, linux-serial, linuxppc-dev, kernel-janitors,
linux-kernel
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 <yuehaibing@huawei.com>
---
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 = &uap->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);
^ permalink raw reply related
* Re: Checkpatch bad Warning (Re: [PATCH] powerpc/kgdb: add kgdb_arch_set/remove_breakpoint())
From: Joe Perches @ 2018-09-20 3:02 UTC (permalink / raw)
To: Christophe Leroy, Andy Whitcroft
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev, linux-kernel
In-Reply-To: <2f5f572a-a28c-9d17-844b-9e1961febf64@c-s.fr>
On Tue, 2018-09-18 at 09:33 +0000, 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.
^ permalink raw reply
* Re: [PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 4:19 UTC (permalink / raw)
To: yuehaibing
Cc: geoff, benh, paulus, mpe, kou.ishizaki, andrew, f.fainelli,
linux-kernel, netdev, linuxppc-dev
In-Reply-To: <20180919102339.13988-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
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 <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [v2,2/4] powerpc/tm: Fix HTM documentation
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao
In-Reply-To: <1529362784-14194-2-git-send-email-leitao@debian.org>
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 <leitao@debian.org>
> Acked-By: Michael Neuling <mikey@neuling.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/96695563cebfb810b09479a9951ebb
cheers
^ permalink raw reply
* Re: powerpc/selftests: Wait all threads to join
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, mikey, rashmicy
In-Reply-To: <1533070557-24432-1-git-send-email-leitao@debian.org>
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 <leitao@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/693b31b2fc1636f0aa7af53136d3b4
cheers
^ permalink raw reply
* Re: pseries/memory-hotplug: Only update DT once per memory DLPAR request
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev; +Cc: jallen
In-Reply-To: <152425618836.15614.7060070452480906952.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
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 <nfont@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/063b8b1251fd069f3740339fca5611
cheers
^ permalink raw reply
* Re: [V3] ocxl: Fix access to the AFU Descriptor Data
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, vaibhav,
andrew.donnellan
In-Reply-To: <1534250715-4543-1-git-send-email-clombard@linux.vnet.ibm.com>
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 <stable@vger.kernel.org> # 4.16
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6f8e45f7eb1bee5efdbe4a9cfe4a45
cheers
^ permalink raw reply
* Re: powerpc/memtrace: Remove memory in chunks
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Rashmica Gupta, bsingharora, mikey, linuxppc-dev, anton; +Cc: Rashmica Gupta
In-Reply-To: <20180817042501.15538-1-rashmica.g@gmail.com>
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 - 0xfffffffff. Hot-removing 1GB from
> 0xf40000000 results in the single resource 0x0-0xfffffffff being split
> into two resources: 0x0-0xf3fffffff and 0xf80000000-0xfffffffff.
>
> When we hot-add the memory back we now have three resources:
> 0x0-0xf3fffffff, 0xf40000000-0xf7fffffff, and 0xf80000000-0xfffffffff.
>
> This is an issue if we try to remove some memory that overlaps
> resources. Eg when trying to remove 2GB at address 0xf40000000,
> 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 <rashmica.g@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/3f7daf3d7582dc6628ac40a9045dd1
cheers
^ permalink raw reply
* Re: [v2,1/3] powerpc/pseries/mm: Introducing FW_FEATURE_BLOCK_REMOVE
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Laurent Dufour, linuxppc-dev, linux-kernel; +Cc: aneesh.kumar, npiggin, paulus
In-Reply-To: <1534775376-22480-2-git-send-email-ldufour@linux.vnet.ibm.com>
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" <aneesh.kumar@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/5600fbe340331e2a25d1b277f9c190
cheers
^ permalink raw reply
* Re: powerpc/64: Remove static branch hints from memset()
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20180821010412.23806-1-anton@ozlabs.org>
On Tue, 2018-08-21 at 01:04:12 UTC, Anton Blanchard wrote:
> From: Anton Blanchard <anton@samba.org>
>
> 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 <anton@samba.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/be54c1216f6689a6eb504e3471d0cb
cheers
^ permalink raw reply
* Re: powerpc/powernv: Don't select the cpufreq governors
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Joel Stanley, Gautham R . Shenoy, linuxppc-dev
In-Reply-To: <20180821021428.23377-1-joel@jms.id.au>
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 <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b0dc0f8618e87f1b2c7f04b977fda1
cheers
^ permalink raw reply
* Re: powerpc/iommu: avoid derefence before pointer check
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, Alistair Popple
In-Reply-To: <1534877088-22303-1-git-send-email-leitao@debian.org>
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 <alistair@popple.id.au>
> Signed-off-by: Breno Leitao <leitao@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/984ecdd68de0fa1f63ce205d6c19ef
cheers
^ permalink raw reply
* Re: [v2] powerpc/xive: Avoid unitialized variable
From: Michael Ellerman @ 2018-09-20 4:20 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, clg
In-Reply-To: <1535066799-8493-1-git-send-email-leitao@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
On Thu, 2018-08-23 at 23:26:39 UTC, Breno Leitao wrote:
> From: Breno Leitao <breno.leitao@gmail.com>
>
> 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 <clg@kaod.org>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8ac9e5bfd8cf41ef106ac97267117e
cheers
^ permalink raw reply
* Re: [1/2] powerpc/prom: Remove VLA in prom_check_platform_support()
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Suraj Jitindar Singh, linuxppc-dev; +Cc: mikey, joel, Suraj Jitindar Singh
In-Reply-To: <20180905020951.10372-2-sjitindarsingh@gmail.com>
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 <sjitindarsingh@gmail.com>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ab91239942a900e209f72488627306
cheers
^ permalink raw reply
* Re: [v5,1/2] powerpc/pseries: Remove prrn_work workqueue
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev; +Cc: johnallen3991, desnesn, haren, pmac
In-Reply-To: <153659142059.7764.7393389361707767600.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
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: c000000775367790 ti: c00000001ebd4000 task.ti: c00000070d140000
> NIP: 0000000000000000 LR: 000000001fb3d050 CTR: 0000000000000000
> REGS: c00000001ebd7d40 TRAP: 0700 Tainted: G X (4.4.126-94.22-default)
> MSR: 8000000102081000 <41,VEC,ME5 CR: 28000002 XER: 20040018 4
> CFAR: 000000001fb3d084 40 419 1 3
> GPR00: 000000000000000040000000000010007 000000001ffff400 000000041fffe200
> GPR04: 000000000000008050000000000000000 000000001fb15fa8 0000000500000500
> GPR08: 000000000001f40040000000000000001 0000000000000000 000005:5200040002
> GPR12: 00000000000000005c000000007a05400 c0000000000e89f8 000000001ed9f668
> GPR16: 000000001fbeff944000000001fbeff94 000000001fb545e4 0000006000000060
> GPR20: ffffffffffffffff4ffffffffffffffff 0000000000000000 0000000000000000
> GPR24: 00000000000000005400000001fb3c000 0000000000000000 000000001fb1b040
> GPR28: 000000001fb240004000000001fb440d8 0000000000000008 0000000000000000
> NIP [0000000000000000] 5 (null)
> LR [000000001fb3d050] 031fb3d050
> Call Trace: 4
> Instruction dump: 4 5:47 12 2
> XXXXXXXX XXXXXXXX XXXXX4XX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX XXXXX5XX XXXXXXXX 60000000 60000000 60000000 60000000
> ---[ 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: c000000747cfa390 ti: c00000074712c000 task.ti: c00000074712c000
> NIP: c0000000008002a8 LR: c000000000090770 CTR: 000000000032e088
> REGS: c00000074712f7b0 TRAP: 0901 Tainted: G D X (4.4.126-94.22-default)
> MSR: 8000000100009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22482044 XER: 20040000
> CFAR: c0000000008002c4 SOFTE: 1
> GPR00: c000000000090770 c00000074712fa30 c000000000f09800 c000000000fa1928 6:02
> GPR04: c000000775f5e000 fffffffffffffffe 0000000000000001 c000000000f42db8
> GPR08: 0000000000000001 0000000080000007 0000000000000000 0000000000000000
> GPR12: 8006210083180000 c000000007a14400
> NIP [c0000000008002a8] _raw_spin_lock+0x68/0xd0
> LR [c000000000090770] mobility_rtas_call+0x50/0x100
> Call Trace: 59 5
> [c00000074712fa60] [c000000000090770] mobility_rtas_call+0x50/0x100
> [c00000074712faf0] [c000000000090b08] pseries_devicetree_update+0xf8/0x530
> [c00000074712fc20] [c000000000031ba4] prrn_work_fn+0x34/0x50
> [c00000074712fc40] [c0000000000e0390] process_one_work+0x1a0/0x4e0
> [c00000074712fcd0] [c0000000000e0870] worker_thread+0x1a0/0x6105:57 2
> [c00000074712fd80] [c0000000000e8b18] kthread+0x128/0x150
> [c00000074712fe30] [c0000000000096f8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> 2c090000 40c20010 7d40192d 40c2fff0 7c2004ac 2fa90000 40de0018 5:540030 3
> e8010010 ebe1fff8 7c0803a6 4e800020 <7c210b78> e92d0000 89290009 792affe3
>
> Signed-off-by: John Allen <jallen@linux.ibm.com>
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cd24e457fd8b2d087d9236700c8d29
cheers
^ permalink raw reply
* Re: powerpc/tm: Fix HFSCR bit for no suspend case
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Michael Neuling; +Cc: mikey, linuxppc-dev, Nicholas Piggin
In-Reply-To: <20180911030756.19583-1-mikey@neuling.org>
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: stable@vger.kernel.org # 4.15+
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Tested-by: Breno Leitao <leitao@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/dd9a8c5a87395b6f05552c3b44e42f
cheers
^ permalink raw reply
* Re: [v10,1/5] powerpc/pseries: Define MCE error event section.
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, Laurent Dufour, Michal Suchanek, Ananth Narayan,
Nicholas Piggin
In-Reply-To: <153667601213.24785.10591974977547181565.stgit@jupiter.in.ibm.com>
On Tue, 2018-09-11 at 14:26:52 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> 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 <mahesh@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/04fce21c9db54695389200b50b0b7a
cheers
^ permalink raw reply
* Re: [v2] selftests/powerpc: Do not fail with reschedule
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, gromero
In-Reply-To: <1536784265-19806-1-git-send-email-leitao@debian.org>
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 <leitao@debian.org>
> Reviewed-by: Gustavo Romero <gromero@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/44d947eff19d64384efc06069509db
cheers
^ permalink raw reply
* Re: PowerPC/VDSO: Correct call frame information
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Alan Modra, Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <20180914034004.GP3174@bubble.grove.modra.org>
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 <amodra@gmail.com>
> Tested-by: Reza Arbab <arbab@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/56d20861c027498b5a1112b4f9f05b
cheers
^ permalink raw reply
* Re: [v2,3/5] powerpc/boot: Ensure _zimage_start is a weak symbol
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Nick Desaulniers
In-Reply-To: <20180914040649.1794-4-joel@jms.id.au>
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$
> 0000000000000058 g .text 0000000000000000 _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$
> 0000000000000058 w .text 0000000000000000 _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 <joel@jms.id.au>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ee9d21b3b3583712029a0db65a4b7c
cheers
^ permalink raw reply
* Re: [v2, 4/5] powerpc: Fix duplicate const clang warning in user access code
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Nick Desaulniers, Anton Blanchard
In-Reply-To: <20180914040649.1794-5-joel@jms.id.au>
On Fri, 2018-09-14 at 04:06:48 UTC, Joel Stanley wrote:
> From: Anton Blanchard <anton@samba.org>
>
> 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 <anton@samba.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e00d93ac9a189673028ac125a74b9b
cheers
^ permalink raw reply
* Re: [1/3] powerpc: remove old GCC version checks
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Nicholas Piggin, Joel Stanley; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20180914050854.6214-2-npiggin@gmail.com>
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 <npiggin@gmail.com>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f2910f0e6835339e6ce82cef22fa15
cheers
^ permalink raw reply
* Re: powerpc/pseries: Disable CPU hotplug across migrations
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev
In-Reply-To: <153721164232.32706.4283915467151746975.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
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 <nfont@linux.vnet.ibm.com>
> Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/85a88cabad57d26d826dd94ea34d3a
cheers
^ permalink raw reply
* Re: [01/12] powerpc/64s/hash: Fix stab_rr off by one initialization
From: Michael Ellerman @ 2018-09-20 4:21 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180914153056.3644-2-npiggin@gmail.com>
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 <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/09b4438db13fa83b6219aee5993711
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox