* [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
From: Pranith Kumar @ 2014-12-27 17:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, supporter:S390, Lai Jiangshan,
Paul E. McKenney, Josh Triplett, Steven Rostedt,
Mathieu Desnoyers, Anton Blanchard, Scott Wood, Andy Fleming,
Tiejun Chen, Daniel Walter, Jens Freimann, Christian Borntraeger,
open list:LINUX FOR POWERPC..., open list, open list:S390
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
There are places which include kvm headers and utilize kvm data structures
without checking if KVM is enabled. In two such archs(s390, ppc64), the current
patch makes the uses of KVM conditional on KVM being enabled. The other option,
which is to enable KVM unconditionally seemed a bit too much as we could easily
figure out KVM only parts and enclose them in ifdefs.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
arch/powerpc/kernel/setup_64.c | 7 ++++++-
arch/s390/kernel/asm-offsets.c | 7 ++++++-
include/linux/notifier.h | 47 ++++++++++++++++++++++++------------------
include/linux/srcu.h | 6 +++++-
4 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4f3cfe1..f55302f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -65,10 +65,13 @@
#include <asm/kexec.h>
#include <asm/mmu_context.h>
#include <asm/code-patching.h>
-#include <asm/kvm_ppc.h>
#include <asm/hugetlb.h>
#include <asm/epapr_hcalls.h>
+#if IS_ENABLED(CONFIG_KVM)
+#include <asm/kvm_ppc.h>
+#endif
+
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
#else
@@ -286,8 +289,10 @@ void __init early_setup(unsigned long dt_ptr)
*/
cpu_ready_for_interrupts();
+#if IS_ENABLED(CONFIG_KVM)
/* Reserve large chunks of memory for use by CMA for KVM */
kvm_cma_reserve();
+#endif
/*
* Reserve any gigantic pages requested on the command line.
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..2813a3c 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -7,12 +7,15 @@
#define ASM_OFFSETS_C
#include <linux/kbuild.h>
-#include <linux/kvm_host.h>
#include <linux/sched.h>
#include <asm/idle.h>
#include <asm/vdso.h>
#include <asm/pgtable.h>
+#if IS_ENABLED(CONFIG_KVM)
+#include <linux/kvm_host.h>
+#endif
+
/*
* Make sure that the compiler is new enough. We want a compiler that
* is known to work with the "Q" assembler constraint.
@@ -182,8 +185,10 @@ int main(void)
DEFINE(__LC_PGM_TDB, offsetof(struct _lowcore, pgm_tdb));
DEFINE(__THREAD_trap_tdb, offsetof(struct task_struct, thread.trap_tdb));
DEFINE(__GMAP_ASCE, offsetof(struct gmap, asce));
+#if IS_ENABLED(CONFIG_KVM)
DEFINE(__SIE_PROG0C, offsetof(struct kvm_s390_sie_block, prog0c));
DEFINE(__SIE_PROG20, offsetof(struct kvm_s390_sie_block, prog20));
+#endif /* CONFIG_KVM */
#endif /* CONFIG_32BIT */
return 0;
}
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d14a4c3..fe4f02a 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -47,6 +47,8 @@
* runtime initialization.
*/
+struct notifier_block;
+
typedef int (*notifier_fn_t)(struct notifier_block *nb,
unsigned long action, void *data);
@@ -70,12 +72,6 @@ struct raw_notifier_head {
struct notifier_block __rcu *head;
};
-struct srcu_notifier_head {
- struct mutex mutex;
- struct srcu_struct srcu;
- struct notifier_block __rcu *head;
-};
-
#define ATOMIC_INIT_NOTIFIER_HEAD(name) do { \
spin_lock_init(&(name)->lock); \
(name)->head = NULL; \
@@ -88,11 +84,6 @@ struct srcu_notifier_head {
(name)->head = NULL; \
} while (0)
-/* srcu_notifier_heads must be initialized and cleaned up dynamically */
-extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
-#define srcu_cleanup_notifier_head(name) \
- cleanup_srcu_struct(&(name)->srcu);
-
#define ATOMIC_NOTIFIER_INIT(name) { \
.lock = __SPIN_LOCK_UNLOCKED(name.lock), \
.head = NULL }
@@ -101,7 +92,6 @@ extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
.head = NULL }
#define RAW_NOTIFIER_INIT(name) { \
.head = NULL }
-/* srcu_notifier_heads cannot be initialized statically */
#define ATOMIC_NOTIFIER_HEAD(name) \
struct atomic_notifier_head name = \
@@ -121,8 +111,6 @@ extern int blocking_notifier_chain_register(struct blocking_notifier_head *nh,
struct notifier_block *nb);
extern int raw_notifier_chain_register(struct raw_notifier_head *nh,
struct notifier_block *nb);
-extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
- struct notifier_block *nb);
extern int blocking_notifier_chain_cond_register(
struct blocking_notifier_head *nh,
@@ -134,8 +122,6 @@ extern int blocking_notifier_chain_unregister(struct blocking_notifier_head *nh,
struct notifier_block *nb);
extern int raw_notifier_chain_unregister(struct raw_notifier_head *nh,
struct notifier_block *nb);
-extern int srcu_notifier_chain_unregister(struct srcu_notifier_head *nh,
- struct notifier_block *nb);
extern int atomic_notifier_call_chain(struct atomic_notifier_head *nh,
unsigned long val, void *v);
@@ -149,10 +135,6 @@ extern int raw_notifier_call_chain(struct raw_notifier_head *nh,
unsigned long val, void *v);
extern int __raw_notifier_call_chain(struct raw_notifier_head *nh,
unsigned long val, void *v, int nr_to_call, int *nr_calls);
-extern int srcu_notifier_call_chain(struct srcu_notifier_head *nh,
- unsigned long val, void *v);
-extern int __srcu_notifier_call_chain(struct srcu_notifier_head *nh,
- unsigned long val, void *v, int nr_to_call, int *nr_calls);
#define NOTIFY_DONE 0x0000 /* Don't care */
#define NOTIFY_OK 0x0001 /* Suits me */
@@ -211,5 +193,30 @@ static inline int notifier_to_errno(int ret)
extern struct blocking_notifier_head reboot_notifier_list;
+#ifdef CONFIG_SRCU
+
+struct srcu_notifier_head {
+ struct mutex mutex;
+ struct srcu_struct srcu;
+ struct notifier_block __rcu *head;
+};
+
+/* srcu_notifier_heads must be initialized and cleaned up dynamically
+ * srcu_notifier_heads cannot be initialized statically
+ */
+extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
+#define srcu_cleanup_notifier_head(name) cleanup_srcu_struct(&(name)->srcu)
+
+extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
+ struct notifier_block *nb);
+extern int srcu_notifier_chain_unregister(struct srcu_notifier_head *nh,
+ struct notifier_block *nb);
+extern int srcu_notifier_call_chain(struct srcu_notifier_head *nh,
+ unsigned long val, void *v);
+extern int __srcu_notifier_call_chain(struct srcu_notifier_head *nh,
+ unsigned long val, void *v, int nr_to_call, int *nr_calls);
+
+#endif /* CONFIG_SRCU */
+
#endif /* __KERNEL__ */
#endif /* _LINUX_NOTIFIER_H */
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 9cfd962..ed9c389 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -26,6 +26,8 @@
*
*/
+#ifdef CONFIG_SRCU
+
#ifndef _LINUX_SRCU_H
#define _LINUX_SRCU_H
@@ -249,4 +251,6 @@ static inline void smp_mb__after_srcu_read_unlock(void)
/* __srcu_read_unlock has smp_mb() internally so nothing to do here. */
}
-#endif
+#endif /* _LINUX_SRCU_H */
+
+#endif /* CONFIG_SRCU */
--
1.9.1
^ permalink raw reply related
* [PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
From: Pranith Kumar @ 2014-12-27 17:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Srivatsa S. Bhat, Rafael J. Wysocki, Gautham R. Shenoy,
Michael Neuling, open list:LINUX FOR POWERPC..., open list
In-Reply-To: <1419700667-24888-1-git-send-email-bobby.prani@gmail.com>
In an allnoconfig we get the following build failure:
arch/powerpc/platforms/built-in.o: In function `.__machine_initcall_powernv_opal_init':
opal.c:(.init.text+0x468): undefined reference to `.log_buf_addr_get'
opal.c:(.init.text+0x474): undefined reference to `.log_buf_len_get'
make: *** [vmlinux] Error 1
This happens because powernv requires printk() support. Enable it in the config
file.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
arch/powerpc/platforms/powernv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
index 45a8ed0..be4f340 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -18,6 +18,7 @@ config PPC_POWERNV
select CPU_FREQ_GOV_ONDEMAND
select CPU_FREQ_GOV_CONSERVATIVE
select PPC_DOORBELL
+ select PRINTK
default y
config PPC_POWERNV_RTAS
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
From: Michael Ellerman @ 2014-12-29 9:01 UTC (permalink / raw)
To: Pranith Kumar
Cc: Gautham R. Shenoy, Michael Neuling, Rafael J. Wysocki, open list,
hegdevasant, Paul Mackerras, Srivatsa S. Bhat,
open list:LINUX FOR POWERPC...
In-Reply-To: <1419700667-24888-2-git-send-email-bobby.prani@gmail.com>
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
> In an allnoconfig we get the following build failure:
An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you
mean.
> arch/powerpc/platforms/built-in.o: In function `.__machine_initcall_powernv_opal_init':
> opal.c:(.init.text+0x468): undefined reference to `.log_buf_addr_get'
> opal.c:(.init.text+0x474): undefined reference to `.log_buf_len_get'
> make: *** [vmlinux] Error 1
>
> This happens because powernv requires printk() support. Enable it in the config
> file.
Sort of. It just requires those two routines. Or is there a stronger
dependency?
I think the better fix is for those two routines to be defined for
CONFIG_PRINTK=n, but return NULL and zero respectively.
And the opal code could skip registering the region when they return NULL/zero.
Care to do a couple of patches?
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Michael Ellerman @ 2014-12-29 9:01 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: scottwood, linuxppc-dev, anton
In-Reply-To: <1419230320-37558-1-git-send-email-dongsheng.wang@freescale.com>
On Mon, 2014-12-22 at 14:38 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Kernel cannot bring up Non-boot cpus always get "Processor xx is stuck".
> this issue bring by http://patchwork.ozlabs.org/patch/418912/ (powerpc:
> Secondary CPUs must set cpu_callin_map after setting active and online)
We've decided we're just going to revert that patch for this cycle.
We'll do a better fix for next, and hopefully people will test it before it
gets to mainline :D
cheers
^ permalink raw reply
* Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
From: Martin Schwidefsky @ 2014-12-29 10:03 UTC (permalink / raw)
To: Pranith Kumar
Cc: open list:S390, Lai Jiangshan, Tiejun Chen, Heiko Carstens,
Josh Triplett, Steven Rostedt, open list, Scott Wood,
Jens Freimann, Paul Mackerras, Anton Blanchard, Andy Fleming,
Mathieu Desnoyers, supporter:S390, Paul E. McKenney,
open list:LINUX FOR POWERPC..., Christian Borntraeger,
Daniel Walter
In-Reply-To: <1419700667-24888-1-git-send-email-bobby.prani@gmail.com>
On Sat, 27 Dec 2014 12:17:43 -0500
Pranith Kumar <bobby.prani@gmail.com> wrote:
> @@ -65,10 +65,13 @@
> #include <asm/kexec.h>
> #include <asm/mmu_context.h>
> #include <asm/code-patching.h>
> -#include <asm/kvm_ppc.h>
> #include <asm/hugetlb.h>
> #include <asm/epapr_hcalls.h>
>
> +#if IS_ENABLED(CONFIG_KVM)
> +#include <asm/kvm_ppc.h>
> +#endif
> +
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
I always cringe when I see an include protected by an #ifdef.
Is this really necessary? All that is done in asm-offsets.c is
to calculate offsets, the code where the two offsets in question
are used (entry64.S) does have the #ifdef for CONFIG_KVM.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH] cleanup on stack DECLARE_COMPLETIONs
From: Dimitri Sivanich @ 2014-12-29 15:38 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: linux-scsi, linux-usb, Felipe Balbi, James E.J. Bottomley,
Juergen E. Fischer, linuxppc-dev
In-Reply-To: <1419356048-22405-1-git-send-email-der.herr@hofr.at>
On Tue, Dec 23, 2014 at 06:34:08PM +0100, Nicholas Mc Guire wrote:
> fixups for incorrect use of DECLARE_COMPLETION. see also commit
> 6e9a4738 ("completions: lockdep annotate on stack completions")
> The only somewhat special case being
> drivers/misc/sgi-gru/grukservices.c:quicktest2
> which had a static qualifier in the original DECLARE_COMPLETION()
> but that seems to be wrong (why should the completion persisted between
> successive calls ?) so the conversion to DECLARE_COMPLETION_ONSTACK
> was also applied and the static qualifier removed.
>
> Not sure if this is suitable in this form or if it should go out as
> 5 seperate patches ?
>
> This was only code reviewed and compile tested
Acking just the drivers/misc/sgi-gru/grukservices.c patch of this set.
Acked-by: Dimitri Sivanich <sivanich@sgi.com>
>
> Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> ---
> drivers/macintosh/ams/ams-pmu.c | 4 ++--
> drivers/misc/sgi-gru/grukservices.c | 2 +-
> drivers/scsi/aha152x.c | 2 +-
> drivers/usb/gadget/udc/fsl_qe_udc.c | 2 +-
> drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/macintosh/ams/ams-pmu.c b/drivers/macintosh/ams/ams-pmu.c
> index 4f61b3e..c2b178f 100644
> --- a/drivers/macintosh/ams/ams-pmu.c
> +++ b/drivers/macintosh/ams/ams-pmu.c
> @@ -52,7 +52,7 @@ static void ams_pmu_req_complete(struct adb_request *req)
> static void ams_pmu_set_register(u8 reg, u8 value)
> {
> static struct adb_request req;
> - DECLARE_COMPLETION(req_complete);
> + DECLARE_COMPLETION_ONSTACK(req_complete);
>
> req.arg = &req_complete;
> if (pmu_request(&req, ams_pmu_req_complete, 4, ams_pmu_cmd, 0x00, reg, value))
> @@ -65,7 +65,7 @@ static void ams_pmu_set_register(u8 reg, u8 value)
> static u8 ams_pmu_get_register(u8 reg)
> {
> static struct adb_request req;
> - DECLARE_COMPLETION(req_complete);
> + DECLARE_COMPLETION_ONSTACK(req_complete);
>
> req.arg = &req_complete;
> if (pmu_request(&req, ams_pmu_req_complete, 3, ams_pmu_cmd, 0x01, reg))
> diff --git a/drivers/misc/sgi-gru/grukservices.c b/drivers/misc/sgi-gru/grukservices.c
> index 913de07..4e412fe 100644
> --- a/drivers/misc/sgi-gru/grukservices.c
> +++ b/drivers/misc/sgi-gru/grukservices.c
> @@ -1044,7 +1044,7 @@ done:
>
> static int quicktest2(unsigned long arg)
> {
> - static DECLARE_COMPLETION(cmp);
> + DECLARE_COMPLETION_ONSTACK(cmp);
> unsigned long han;
> int blade_id = 0;
> int numcb = 4;
> diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
> index 2b960b3..b16afb9 100644
> --- a/drivers/scsi/aha152x.c
> +++ b/drivers/scsi/aha152x.c
> @@ -1055,7 +1055,7 @@ static int aha152x_abort(Scsi_Cmnd *SCpnt)
> static int aha152x_device_reset(Scsi_Cmnd * SCpnt)
> {
> struct Scsi_Host *shpnt = SCpnt->device->host;
> - DECLARE_COMPLETION(done);
> + DECLARE_COMPLETION_ONSTACK(done);
> int ret, issued, disconnected;
> unsigned char old_cmd_len = SCpnt->cmd_len;
> unsigned long flags;
> diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c b/drivers/usb/gadget/udc/fsl_qe_udc.c
> index 795c99c..e0822f1 100644
> --- a/drivers/usb/gadget/udc/fsl_qe_udc.c
> +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
> @@ -2630,7 +2630,7 @@ static int qe_udc_remove(struct platform_device *ofdev)
> struct qe_udc *udc = platform_get_drvdata(ofdev);
> struct qe_ep *ep;
> unsigned int size;
> - DECLARE_COMPLETION(done);
> + DECLARE_COMPLETION_ONSTACK(done);
>
> usb_del_gadget_udc(&udc->gadget);
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
> index 2df8074..c3830ad 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2529,7 +2529,7 @@ static int __exit fsl_udc_remove(struct platform_device *pdev)
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> struct fsl_usb2_platform_data *pdata = dev_get_platdata(&pdev->dev);
>
> - DECLARE_COMPLETION(done);
> + DECLARE_COMPLETION_ONSTACK(done);
>
> if (!udc_controller)
> return -ENODEV;
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH] macintosh: ams: cleanup on stack DECLARE_COMPLETION
From: Nicholas Mc Guire @ 2014-12-29 19:59 UTC (permalink / raw)
To: Michael Hanselmann
Cc: devicetree, linux-kernel, Rob Herring, Nicholas Mc Guire,
Grant Likely, linuxppc-dev
fix-up for incorrect use of DECLARE_COMPLETION. see also commit
6e9a4738 ("completions: lockdep annotate on stack completions")
V2: split out patch for individual files and (hopefully) proper
labeling this time
patch is against linux-next 3.19.0-rc1 -next-20141226
patch was compile tested with ppc6xx_defconfig, CONFIG_SENSORS_AMS=m,
CONFIG_SENSORS_AMS_PMU=y
Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
---
drivers/macintosh/ams/ams-pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/ams/ams-pmu.c b/drivers/macintosh/ams/ams-pmu.c
index 4f61b3e..c2b178f 100644
--- a/drivers/macintosh/ams/ams-pmu.c
+++ b/drivers/macintosh/ams/ams-pmu.c
@@ -52,7 +52,7 @@ static void ams_pmu_req_complete(struct adb_request *req)
static void ams_pmu_set_register(u8 reg, u8 value)
{
static struct adb_request req;
- DECLARE_COMPLETION(req_complete);
+ DECLARE_COMPLETION_ONSTACK(req_complete);
req.arg = &req_complete;
if (pmu_request(&req, ams_pmu_req_complete, 4, ams_pmu_cmd, 0x00, reg, value))
@@ -65,7 +65,7 @@ static void ams_pmu_set_register(u8 reg, u8 value)
static u8 ams_pmu_get_register(u8 reg)
{
static struct adb_request req;
- DECLARE_COMPLETION(req_complete);
+ DECLARE_COMPLETION_ONSTACK(req_complete);
req.arg = &req_complete;
if (pmu_request(&req, ams_pmu_req_complete, 3, ams_pmu_cmd, 0x01, reg))
--
1.7.10.4
^ permalink raw reply related
* Re: Build regressions/improvements in v3.19-rc2
From: Geert Uytterhoeven @ 2014-12-29 20:22 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: the arch/x86 maintainers, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1419883144-13523-1-git-send-email-geert@linux-m68k.org>
On Mon, Dec 29, 2014 at 8:59 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.19-rc2[1] to v3.19-rc1[3], the summaries are:
> - build errors: +8/-5
Surprise! No new R_PPC64_REL24 relocation truncations, hence not much new
generic code was added. Bloat-o-meter on atari_defconfig agrees: +36 bytes.
+ /home/kisskb/slave/src/arch/powerpc/platforms/pseries/hotplug-memory.c:
error: 'SECTION_SIZE_BITS' undeclared (first use in this function):
=> 27:31
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error:
'PAGES_PER_SECTION' undeclared (first use in this function): =>
1836:46, 1178:18
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error:
'PAGE_SECTION_MASK' undeclared (first use in this function): =>
1177:20
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function '__nr_to_section'
[-Werror=implicit-function-declaration]: => 1841:3
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function 'find_memory_block_hinted'
[-Werror=implicit-function-declaration]: => 1848:3
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function 'pfn_to_section_nr'
[-Werror=implicit-function-declaration]: => 1837:3
+ /home/kisskb/slave/src/mm/memory_hotplug.c: error: implicit
declaration of function 'present_section_nr'
[-Werror=implicit-function-declaration]: => 1838:3
powerpc-randconfig
+ error: initramfs.c: undefined reference to `__stack_chk_guard':
=> .init.text+0x3132)
i386-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/8257/ (all 262 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/8241/ (all 262 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
From: Scott Wood @ 2014-12-29 23:05 UTC (permalink / raw)
To: Pranith Kumar
Cc: open list:S390, Lai Jiangshan, Christian Borntraeger,
open list:LINUX FOR POWERPC..., Heiko Carstens, Josh Triplett,
Steven Rostedt, open list, Tiejun Chen, Jens Freimann,
Paul Mackerras, Anton Blanchard, Andy Fleming, Martin Schwidefsky,
supporter:S390, Paul E. McKenney, Daniel Walter,
Mathieu Desnoyers
In-Reply-To: <1419700667-24888-1-git-send-email-bobby.prani@gmail.com>
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
> Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
> is a compile time failure if srcu is used when not enabled. This was decided to
> be better than waiting until link time for a failure to occur.
Yes, false positives and extra ifdefs are so much better. :-P
Why not just ifdef the functions/macros, and leave the types alone? If
you're worried about direct access to struct members, you could even
ifdef the members away while leaving the struct itself. It is not
normal practice in Linux to need ifdefs around #includes.
> There are places which include kvm headers and utilize kvm data structures
> without checking if KVM is enabled. In two such archs(s390, ppc64), the current
> patch makes the uses of KVM conditional on KVM being enabled. The other option,
> which is to enable KVM unconditionally seemed a bit too much as we could easily
> figure out KVM only parts and enclose them in ifdefs.
Maybe not so easy (mpc85xx_smp_defconfig with NOTIFY stuff turned off so
that SRCU gets deselected):
In file included from /home/scott/fsl/git/linux/upstream/arch/powerpc/include/asm/kvm_ppc.h:30:0,
from /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/smp.c:39:
/home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
/home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
/home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'arch/powerpc/kernel/smp.o' failed
make[2]: *** [arch/powerpc/kernel/smp.o] Error 1
/home/scott/fsl/git/linux/upstream/Makefile:955: recipe for target 'arch/powerpc/kernel' failed
make[1]: *** [arch/powerpc/kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
Are you sure KVM is the only SRCU user so impacted? It's also likely
that new such problems get introduced, because most people are going to
have SRCU enabled and thus not notice the breakage they're adding.
There's also at least one place that needs to be fixed, that currently
expects to get other headers indirectly via srcu.h:
/home/scott/fsl/git/linux/upstream/lib/assoc_array.c: In function 'assoc_array_apply_edit':
/home/scott/fsl/git/linux/upstream/lib/assoc_array.c:1425:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
/home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'lib/assoc_array.o' failed
-Scott
^ permalink raw reply
* [PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
From: Nicolin Chen @ 2014-12-30 0:13 UTC (permalink / raw)
To: broonie
Cc: alsa-devel, lgirdwood, festevam, Xiubo.Lee, timur, linux-kernel,
a_bouin, linuxppc-dev
The xDC field should have 5 bit width according to Reference Manual.
Thus this patch fixes it.
Signed-off-by: Aurelien BOUIN <a_bouin@yahoo.fr>
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
The patch was originally submitted by Aurelien BOUIN while in an
informal way. And he hasn't finished any re-submitting during the
past two weeks. Thus I create a new patch with his signed-off
included so as to fix the probelm as soon as possible, not sure
whether it's decent or not though.
--Nicolin
sound/soc/fsl/fsl_esai.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_esai.h b/sound/soc/fsl/fsl_esai.h
index 91a550f..5e793bb 100644
--- a/sound/soc/fsl/fsl_esai.h
+++ b/sound/soc/fsl/fsl_esai.h
@@ -302,7 +302,7 @@
#define ESAI_xCCR_xFP_MASK (((1 << ESAI_xCCR_xFP_WIDTH) - 1) << ESAI_xCCR_xFP_SHIFT)
#define ESAI_xCCR_xFP(v) ((((v) - 1) << ESAI_xCCR_xFP_SHIFT) & ESAI_xCCR_xFP_MASK)
#define ESAI_xCCR_xDC_SHIFT 9
-#define ESAI_xCCR_xDC_WIDTH 4
+#define ESAI_xCCR_xDC_WIDTH 5
#define ESAI_xCCR_xDC_MASK (((1 << ESAI_xCCR_xDC_WIDTH) - 1) << ESAI_xCCR_xDC_SHIFT)
#define ESAI_xCCR_xDC(v) ((((v) - 1) << ESAI_xCCR_xDC_SHIFT) & ESAI_xCCR_xDC_MASK)
#define ESAI_xCCR_xPSR_SHIFT 8
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
From: Pranith Kumar @ 2014-12-30 4:32 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: open list:S390, Lai Jiangshan, Tiejun Chen, Heiko Carstens,
Josh Triplett, Steven Rostedt, open list, Scott Wood,
Jens Freimann, Paul Mackerras, Anton Blanchard, Andy Fleming,
Mathieu Desnoyers, supporter:S390, Paul E. McKenney,
open list:LINUX FOR POWERPC..., Christian Borntraeger,
Daniel Walter
In-Reply-To: <20141229110324.50f1339b@mschwide>
On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
> On Sat, 27 Dec 2014 12:17:43 -0500
> Pranith Kumar <bobby.prani@gmail.com> wrote:
>
>> @@ -65,10 +65,13 @@
>> #include <asm/kexec.h>
>> #include <asm/mmu_context.h>
>> #include <asm/code-patching.h>
>> -#include <asm/kvm_ppc.h>
>> #include <asm/hugetlb.h>
>> #include <asm/epapr_hcalls.h>
>>
>> +#if IS_ENABLED(CONFIG_KVM)
>> +#include <asm/kvm_ppc.h>
>> +#endif
>> +
>> #ifdef DEBUG
>> #define DBG(fmt...) udbg_printf(fmt)
>> #else
>
> I always cringe when I see an include protected by an #ifdef.
> Is this really necessary? All that is done in asm-offsets.c is
> to calculate offsets, the code where the two offsets in question
> are used (entry64.S) does have the #ifdef for CONFIG_KVM.
I agree that this is not the ideal way to do this. But, it has been
the way things were already being done. If you see
arch/powerpc/kernel/asm-offsets.c, there are quite some includes which
are within ifdefs.
I've considered other alternatives (though not in-depth) and found
that they will require quite some refactoring. One simple idea is to
move this #ifdef to within kvm_ppc.h. That should make the inclusion
of this file a no-op in all the places where this is being included
without KVM being enabled. But I am not 100% sure of that approach.
Any suggestions are welcome.
--
Pranith
^ permalink raw reply
* [PATCH] tty: 8250: Add 64byte UART support for FSL platforms
From: Vijay Rai @ 2014-12-30 9:38 UTC (permalink / raw)
To: gregkh, linux-serial, linux-kernel, linuxppc-dev
Cc: Vijay Rai, Poonam Aggrwal, Priyanka Jain
Some of FSL SoCs like T1040 has new version of UART controller which
can support 64byte FiFo.
To enable 64 byte support, following needs to be done:
-FCR[EN64] needs to be programmed to 1 to enable it.
-Also, when FCR[EN64]==1, RTL bits to be used as below
to define various Receive Trigger Levels:
-FCR[RTL] = 00 1 byte
-FCR[RTL] = 01 16 bytes
-FCR[RTL] = 10 32 bytes
-FCR[RTL] = 11 56 bytes
-tx_loadsz is set to 32-bytes instead of 64-bytes to implement
workaround of errata A-008006 which states that tx_loadsz should
be configured less than Maximum supported fifo bytes
Signed-off-by: Vijay Rai <vijay.rai@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
---
drivers/tty/serial/8250/8250_core.c | 20 +++++++++++++++++++-
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 3 ++-
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 11c6685..565748c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -329,6 +329,14 @@ static const struct serial8250_config uart_config[] = {
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE,
},
+ [PORT_16550A_FSL64] = {
+ .name = "16550A_FSL64",
+ .fifo_size = 64,
+ .tx_loadsz = 32,
+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
+ UART_FCR7_64BYTE,
+ .flags = UART_CAP_FIFO,
+ },
};
/* Uart divisor latch read */
@@ -956,7 +964,17 @@ static void autoconfig_16550a(struct uart_8250_port *up)
up->port.type = PORT_16650;
up->capabilities |= UART_CAP_EFR | UART_CAP_SLEEP;
} else {
- DEBUG_AUTOCONF("Motorola 8xxx DUART ");
+ serial_out(up, UART_LCR, 0);
+ serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO |
+ UART_FCR7_64BYTE);
+ status1 = serial_in(up, UART_IIR) >> 5;
+ serial_out(up, UART_FCR, 0);
+ serial_out(up, UART_LCR, 0);
+
+ if (status1 == 7)
+ up->port.type = PORT_16550A_FSL64;
+ else
+ DEBUG_AUTOCONF("Motorola 8xxx DUART ");
}
serial_out(up, UART_EFR, 0);
return;
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index c172180..a3b4491 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -55,7 +55,8 @@
#define PORT_ALTR_16550_F64 27 /* Altera 16550 UART with 64 FIFOs */
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
-#define PORT_MAX_8250 29 /* max port ID */
+#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index 53af3b7..00adb01 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -86,7 +86,8 @@
#define UART_FCR6_T_TRIGGER_8 0x10 /* Mask for transmit trigger set at 8 */
#define UART_FCR6_T_TRIGGER_24 0x20 /* Mask for transmit trigger set at 24 */
#define UART_FCR6_T_TRIGGER_30 0x30 /* Mask for transmit trigger set at 30 */
-#define UART_FCR7_64BYTE 0x20 /* Go into 64 byte mode (TI16C750) */
+#define UART_FCR7_64BYTE 0x20 /* Go into 64 byte mode (TI16C750 and
+ some Freescale UARTs) */
#define UART_FCR_R_TRIG_SHIFT 6
#define UART_FCR_R_TRIG_BITS(x) \
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
From: Pranith Kumar @ 2014-12-30 5:06 UTC (permalink / raw)
To: Scott Wood
Cc: open list:S390, Lai Jiangshan, Christian Borntraeger,
open list:LINUX FOR POWERPC..., Heiko Carstens, Josh Triplett,
Steven Rostedt, open list, Tiejun Chen, Jens Freimann,
Paul Mackerras, Anton Blanchard, Andy Fleming, Martin Schwidefsky,
supporter:S390, Paul E. McKenney, Daniel Walter,
Mathieu Desnoyers
In-Reply-To: <1419894305.4961.2.camel@freescale.com>
On Mon, Dec 29, 2014 at 6:05 PM, Scott Wood <scottwood@freescale.com> wrote:
> On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
>> Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
>> is a compile time failure if srcu is used when not enabled. This was decided to
>> be better than waiting until link time for a failure to occur.
>
> Yes, false positives and extra ifdefs are so much better. :-P
>
> Why not just ifdef the functions/macros, and leave the types alone? If
> you're worried about direct access to struct members, you could even
> ifdef the members away while leaving the struct itself. It is not
> normal practice in Linux to need ifdefs around #includes.
Yup, totally agree that this is not ideal. The idea here is to not
even compile the structure for tinification purposes. ifdefs for
headers are ugly, but given the current code structure, I was not able
to figure out any other way around it without major overhaul.
>
>> There are places which include kvm headers and utilize kvm data structures
>> without checking if KVM is enabled. In two such archs(s390, ppc64), the current
>> patch makes the uses of KVM conditional on KVM being enabled. The other option,
>> which is to enable KVM unconditionally seemed a bit too much as we could easily
>> figure out KVM only parts and enclose them in ifdefs.
>
> Maybe not so easy (mpc85xx_smp_defconfig with NOTIFY stuff turned off so
> that SRCU gets deselected):
>
> In file included from /home/scott/fsl/git/linux/upstream/arch/powerpc/include/asm/kvm_ppc.h:30:0,
> from /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/smp.c:39:
> /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
> /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
> /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'arch/powerpc/kernel/smp.o' failed
> make[2]: *** [arch/powerpc/kernel/smp.o] Error 1
> /home/scott/fsl/git/linux/upstream/Makefile:955: recipe for target 'arch/powerpc/kernel' failed
> make[1]: *** [arch/powerpc/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> Are you sure KVM is the only SRCU user so impacted? It's also likely
> that new such problems get introduced, because most people are going to
> have SRCU enabled and thus not notice the breakage they're adding.
Well, it is the major one which I encountered until now. There might
be other problems lurking which I will gladly try to fix if and when
they are reported.
>
> There's also at least one place that needs to be fixed, that currently
> expects to get other headers indirectly via srcu.h:
>
> /home/scott/fsl/git/linux/upstream/lib/assoc_array.c: In function 'assoc_array_apply_edit':
> /home/scott/fsl/git/linux/upstream/lib/assoc_array.c:1425:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'lib/assoc_array.o' failed
I will send a patch fixing this(need to use rcupdate.h here
explicitly). Thanks for reporting these!
>
> -Scott
>
>
--
Pranith
^ permalink raw reply
* [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
From: Pranith Kumar @ 2014-12-30 5:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, supporter:S390, Lai Jiangshan,
Paul E. McKenney, Josh Triplett, Steven Rostedt,
Mathieu Desnoyers, Scott Wood, Anton Blanchard, Daniel Walter,
Tiejun Chen, Nishanth Aravamudan, Ingo Molnar, Peter Zijlstra,
Srivatsa S. Bhat, Vincent Guittot, Li Zhong,
Christian Borntraeger, Jens Freimann,
open list:LINUX FOR POWERPC..., open list, open list:S390
In-Reply-To: <1419918382-4758-1-git-send-email-bobby.prani@gmail.com>
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
There are places which include kvm headers and utilize kvm data structures
without checking if KVM is enabled. In two such archs(s390, ppc64), the current
patch makes the uses of KVM conditional on KVM being enabled. The other option,
which is to enable KVM unconditionally seemed a bit too much as we could easily
figure out KVM only parts and enclose them in ifdefs.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
CC: Scott Wood <scottwood@freescale.com>
---
v2:
- fix build failures reported by Scott Wood
arch/powerpc/kernel/setup_64.c | 7 ++++++-
arch/powerpc/kernel/smp.c | 9 +++++++-
arch/s390/kernel/asm-offsets.c | 7 ++++++-
include/linux/notifier.h | 47 ++++++++++++++++++++++++------------------
include/linux/srcu.h | 6 +++++-
5 files changed, 52 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4f3cfe1..f55302f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -65,10 +65,13 @@
#include <asm/kexec.h>
#include <asm/mmu_context.h>
#include <asm/code-patching.h>
-#include <asm/kvm_ppc.h>
#include <asm/hugetlb.h>
#include <asm/epapr_hcalls.h>
+#if IS_ENABLED(CONFIG_KVM)
+#include <asm/kvm_ppc.h>
+#endif
+
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
#else
@@ -286,8 +289,10 @@ void __init early_setup(unsigned long dt_ptr)
*/
cpu_ready_for_interrupts();
+#if IS_ENABLED(CONFIG_KVM)
/* Reserve large chunks of memory for use by CMA for KVM */
kvm_cma_reserve();
+#endif
/*
* Reserve any gigantic pages requested on the command line.
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 71e186d..0001daa 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -36,7 +36,6 @@
#include <linux/atomic.h>
#include <asm/irq.h>
#include <asm/hw_irq.h>
-#include <asm/kvm_ppc.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/prom.h>
@@ -54,6 +53,10 @@
#include <asm/debug.h>
#include <asm/kexec.h>
+#if IS_ENABLED(CONFIG_KVM)
+#include <asm/kvm_ppc.h>
+#endif
+
#ifdef DEBUG
#include <asm/udbg.h>
#define DBG(fmt...) udbg_printf(fmt)
@@ -470,7 +473,11 @@ int generic_check_cpu_restart(unsigned int cpu)
static bool secondaries_inhibited(void)
{
+#if IS_ENABLED(CONFIG_KVM)
return kvm_hv_mode_active();
+#else
+ return false;
+#endif
}
#else /* HOTPLUG_CPU */
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..2813a3c 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -7,12 +7,15 @@
#define ASM_OFFSETS_C
#include <linux/kbuild.h>
-#include <linux/kvm_host.h>
#include <linux/sched.h>
#include <asm/idle.h>
#include <asm/vdso.h>
#include <asm/pgtable.h>
+#if IS_ENABLED(CONFIG_KVM)
+#include <linux/kvm_host.h>
+#endif
+
/*
* Make sure that the compiler is new enough. We want a compiler that
* is known to work with the "Q" assembler constraint.
@@ -182,8 +185,10 @@ int main(void)
DEFINE(__LC_PGM_TDB, offsetof(struct _lowcore, pgm_tdb));
DEFINE(__THREAD_trap_tdb, offsetof(struct task_struct, thread.trap_tdb));
DEFINE(__GMAP_ASCE, offsetof(struct gmap, asce));
+#if IS_ENABLED(CONFIG_KVM)
DEFINE(__SIE_PROG0C, offsetof(struct kvm_s390_sie_block, prog0c));
DEFINE(__SIE_PROG20, offsetof(struct kvm_s390_sie_block, prog20));
+#endif /* CONFIG_KVM */
#endif /* CONFIG_32BIT */
return 0;
}
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d14a4c3..fe4f02a 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -47,6 +47,8 @@
* runtime initialization.
*/
+struct notifier_block;
+
typedef int (*notifier_fn_t)(struct notifier_block *nb,
unsigned long action, void *data);
@@ -70,12 +72,6 @@ struct raw_notifier_head {
struct notifier_block __rcu *head;
};
-struct srcu_notifier_head {
- struct mutex mutex;
- struct srcu_struct srcu;
- struct notifier_block __rcu *head;
-};
-
#define ATOMIC_INIT_NOTIFIER_HEAD(name) do { \
spin_lock_init(&(name)->lock); \
(name)->head = NULL; \
@@ -88,11 +84,6 @@ struct srcu_notifier_head {
(name)->head = NULL; \
} while (0)
-/* srcu_notifier_heads must be initialized and cleaned up dynamically */
-extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
-#define srcu_cleanup_notifier_head(name) \
- cleanup_srcu_struct(&(name)->srcu);
-
#define ATOMIC_NOTIFIER_INIT(name) { \
.lock = __SPIN_LOCK_UNLOCKED(name.lock), \
.head = NULL }
@@ -101,7 +92,6 @@ extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
.head = NULL }
#define RAW_NOTIFIER_INIT(name) { \
.head = NULL }
-/* srcu_notifier_heads cannot be initialized statically */
#define ATOMIC_NOTIFIER_HEAD(name) \
struct atomic_notifier_head name = \
@@ -121,8 +111,6 @@ extern int blocking_notifier_chain_register(struct blocking_notifier_head *nh,
struct notifier_block *nb);
extern int raw_notifier_chain_register(struct raw_notifier_head *nh,
struct notifier_block *nb);
-extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
- struct notifier_block *nb);
extern int blocking_notifier_chain_cond_register(
struct blocking_notifier_head *nh,
@@ -134,8 +122,6 @@ extern int blocking_notifier_chain_unregister(struct blocking_notifier_head *nh,
struct notifier_block *nb);
extern int raw_notifier_chain_unregister(struct raw_notifier_head *nh,
struct notifier_block *nb);
-extern int srcu_notifier_chain_unregister(struct srcu_notifier_head *nh,
- struct notifier_block *nb);
extern int atomic_notifier_call_chain(struct atomic_notifier_head *nh,
unsigned long val, void *v);
@@ -149,10 +135,6 @@ extern int raw_notifier_call_chain(struct raw_notifier_head *nh,
unsigned long val, void *v);
extern int __raw_notifier_call_chain(struct raw_notifier_head *nh,
unsigned long val, void *v, int nr_to_call, int *nr_calls);
-extern int srcu_notifier_call_chain(struct srcu_notifier_head *nh,
- unsigned long val, void *v);
-extern int __srcu_notifier_call_chain(struct srcu_notifier_head *nh,
- unsigned long val, void *v, int nr_to_call, int *nr_calls);
#define NOTIFY_DONE 0x0000 /* Don't care */
#define NOTIFY_OK 0x0001 /* Suits me */
@@ -211,5 +193,30 @@ static inline int notifier_to_errno(int ret)
extern struct blocking_notifier_head reboot_notifier_list;
+#ifdef CONFIG_SRCU
+
+struct srcu_notifier_head {
+ struct mutex mutex;
+ struct srcu_struct srcu;
+ struct notifier_block __rcu *head;
+};
+
+/* srcu_notifier_heads must be initialized and cleaned up dynamically
+ * srcu_notifier_heads cannot be initialized statically
+ */
+extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
+#define srcu_cleanup_notifier_head(name) cleanup_srcu_struct(&(name)->srcu)
+
+extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
+ struct notifier_block *nb);
+extern int srcu_notifier_chain_unregister(struct srcu_notifier_head *nh,
+ struct notifier_block *nb);
+extern int srcu_notifier_call_chain(struct srcu_notifier_head *nh,
+ unsigned long val, void *v);
+extern int __srcu_notifier_call_chain(struct srcu_notifier_head *nh,
+ unsigned long val, void *v, int nr_to_call, int *nr_calls);
+
+#endif /* CONFIG_SRCU */
+
#endif /* __KERNEL__ */
#endif /* _LINUX_NOTIFIER_H */
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 9cfd962..ed9c389 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -26,6 +26,8 @@
*
*/
+#ifdef CONFIG_SRCU
+
#ifndef _LINUX_SRCU_H
#define _LINUX_SRCU_H
@@ -249,4 +251,6 @@ static inline void smp_mb__after_srcu_read_unlock(void)
/* __srcu_read_unlock has smp_mb() internally so nothing to do here. */
}
-#endif
+#endif /* _LINUX_SRCU_H */
+
+#endif /* CONFIG_SRCU */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
From: Pranith Kumar @ 2014-12-30 5:46 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Michael Neuling, Rafael J. Wysocki, open list,
hegdevasant, Paul Mackerras, Srivatsa S. Bhat,
open list:LINUX FOR POWERPC...
In-Reply-To: <1419843707.30395.5.camel@ellerman.id.au>
On Mon, Dec 29, 2014 at 4:01 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
>> In an allnoconfig we get the following build failure:
>
> An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you
> mean.
>
>> arch/powerpc/platforms/built-in.o: In function `.__machine_initcall_powernv_opal_init':
>> opal.c:(.init.text+0x468): undefined reference to `.log_buf_addr_get'
>> opal.c:(.init.text+0x474): undefined reference to `.log_buf_len_get'
>> make: *** [vmlinux] Error 1
>>
>> This happens because powernv requires printk() support. Enable it in the config
>> file.
>
> Sort of. It just requires those two routines. Or is there a stronger
> dependency?
>
> I think the better fix is for those two routines to be defined for
> CONFIG_PRINTK=n, but return NULL and zero respectively.
>
> And the opal code could skip registering the region when they return NULL/zero.
>
> Care to do a couple of patches?
>
Sure, I will give it a try. Thanks for the review!
--
Pranith
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
From: Mark Brown @ 2014-12-30 11:28 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel, lgirdwood, festevam, Xiubo.Lee, timur, linux-kernel,
a_bouin, linuxppc-dev
In-Reply-To: <1419898431-11336-1-git-send-email-nicoleotsuka@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 179 bytes --]
On Mon, Dec 29, 2014 at 04:13:51PM -0800, Nicolin Chen wrote:
> The xDC field should have 5 bit width according to Reference Manual.
> Thus this patch fixes it.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
From: Mark Brown @ 2014-12-30 11:29 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel, lgirdwood, festevam, Xiubo.Lee, timur, linux-kernel,
a_bouin, linuxppc-dev
In-Reply-To: <1419898431-11336-1-git-send-email-nicoleotsuka@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 224 bytes --]
On Mon, Dec 29, 2014 at 04:13:51PM -0800, Nicolin Chen wrote:
> The xDC field should have 5 bit width according to Reference Manual.
> Thus this patch fixes it.
Applied, thanks - I also fixed the patch author up to be him.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
From: Peter Zijlstra @ 2014-12-30 18:50 UTC (permalink / raw)
To: Pranith Kumar
Cc: Heiko Carstens, Tiejun Chen, Paul Mackerras, Daniel Walter,
Ingo Molnar, open list:S390, Vincent Guittot,
Christian Borntraeger, Jens Freimann, Paul E. McKenney,
Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Anton Blanchard,
Scott Wood, Lai Jiangshan, Li Zhong, Nishanth Aravamudan,
open list, Srivatsa S. Bhat, Martin Schwidefsky, supporter:S390,
open list:LINUX FOR POWERPC...
In-Reply-To: <1419918382-4758-2-git-send-email-bobby.prani@gmail.com>
On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
> Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
> is a compile time failure if srcu is used when not enabled. This was decided to
> be better than waiting until link time for a failure to occur.
Why?
^ permalink raw reply
* Re: [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
From: Pranith Kumar @ 2014-12-30 18:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Heiko Carstens, Tiejun Chen, Paul Mackerras, Daniel Walter,
Ingo Molnar, open list:S390, Vincent Guittot,
Christian Borntraeger, Jens Freimann, Paul E. McKenney,
Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Anton Blanchard,
Scott Wood, Lai Jiangshan, Li Zhong, Nishanth Aravamudan,
open list, Srivatsa S. Bhat, Martin Schwidefsky, supporter:S390,
open list:LINUX FOR POWERPC...
In-Reply-To: <20141230185008.GA23965@worktop.programming.kicks-ass.net>
On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
>> Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
>> is a compile time failure if srcu is used when not enabled. This was decided to
>> be better than waiting until link time for a failure to occur.
>
> Why?
This is part of the kernel tinification efforts. The first patch was
posted here: https://lkml.org/lkml/2014/12/4/848. This patch enables a
compile time failure instead of a link time failure.
Thanks!
--
Pranith
^ permalink raw reply
* Re: [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
From: Peter Zijlstra @ 2014-12-30 19:07 UTC (permalink / raw)
To: Pranith Kumar
Cc: Heiko Carstens, Tiejun Chen, Paul Mackerras, Daniel Walter,
Ingo Molnar, open list:S390, Vincent Guittot,
Christian Borntraeger, Jens Freimann, Paul E. McKenney,
Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Anton Blanchard,
Scott Wood, Lai Jiangshan, Li Zhong, Nishanth Aravamudan,
open list, Srivatsa S. Bhat, Martin Schwidefsky, supporter:S390,
open list:LINUX FOR POWERPC...
In-Reply-To: <CAJhHMCDsxOsBKphPrH8N5ymPgdN_OVSujQWQt5CB52TK2PO9cA@mail.gmail.com>
On Tue, Dec 30, 2014 at 01:54:07PM -0500, Pranith Kumar wrote:
> On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
> >> Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
> >> is a compile time failure if srcu is used when not enabled. This was decided to
> >> be better than waiting until link time for a failure to occur.
> >
> > Why?
>
> This is part of the kernel tinification efforts. The first patch was
> posted here: https://lkml.org/lkml/2014/12/4/848. This patch enables a
> compile time failure instead of a link time failure.
can't be arsed to click. again, why does it matter when it fails,
neither stages produces a working kernel so tinification cannot be the
purpose.
^ permalink raw reply
* Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
From: Scott Wood @ 2014-12-30 19:44 UTC (permalink / raw)
To: Pranith Kumar
Cc: open list:S390, Lai Jiangshan, Christian Borntraeger,
open list:LINUX FOR POWERPC..., Heiko Carstens, Josh Triplett,
Steven Rostedt, open list, Tiejun Chen, Jens Freimann,
Paul Mackerras, Anton Blanchard, Andy Fleming, Martin Schwidefsky,
supporter:S390, Paul E. McKenney, Daniel Walter,
Mathieu Desnoyers
In-Reply-To: <CAJhHMCDan+qaaZjVUucA-sUS8A3vSTYuVHg8XQv4rsHXxAzKLw@mail.gmail.com>
On Mon, 2014-12-29 at 23:32 -0500, Pranith Kumar wrote:
> On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky
> <schwidefsky@de.ibm.com> wrote:
> > On Sat, 27 Dec 2014 12:17:43 -0500
> > Pranith Kumar <bobby.prani@gmail.com> wrote:
> >
> >> @@ -65,10 +65,13 @@
> >> #include <asm/kexec.h>
> >> #include <asm/mmu_context.h>
> >> #include <asm/code-patching.h>
> >> -#include <asm/kvm_ppc.h>
> >> #include <asm/hugetlb.h>
> >> #include <asm/epapr_hcalls.h>
> >>
> >> +#if IS_ENABLED(CONFIG_KVM)
> >> +#include <asm/kvm_ppc.h>
> >> +#endif
> >> +
> >> #ifdef DEBUG
> >> #define DBG(fmt...) udbg_printf(fmt)
> >> #else
> >
> > I always cringe when I see an include protected by an #ifdef.
> > Is this really necessary? All that is done in asm-offsets.c is
> > to calculate offsets, the code where the two offsets in question
> > are used (entry64.S) does have the #ifdef for CONFIG_KVM.
>
> I agree that this is not the ideal way to do this. But, it has been
> the way things were already being done. If you see
> arch/powerpc/kernel/asm-offsets.c, there are quite some includes which
> are within ifdefs.
asm-offsets.c is unusual in that respect, and I think most of those
ifdefs could go away without breaking anything (head_booke.h is not a
normal header file, and kvm_book3s.h should just be removed as it will
be pulled in by kvm_ppc.h if applicable).
> I've considered other alternatives (though not in-depth) and found
> that they will require quite some refactoring. One simple idea is to
> move this #ifdef to within kvm_ppc.h. That should make the inclusion
> of this file a no-op in all the places where this is being included
> without KVM being enabled. But I am not 100% sure of that approach.
>
> Any suggestions are welcome.
As I suggested elsewhere in the thread, why not be more fine-grained in
what you ifdef in the srcu header? How will that require excessive
refactoring?
Or, just stick with the linker error.
I also wonder if this is worthwhile just to save around 2000 bytes.
What other core synchronization mechanisms are optional? What
real-world configs will actually have this disabled?
-Scott
^ permalink raw reply
* Re: [PATCH] tty: 8250: Add 64byte UART support for FSL platforms
From: Scott Wood @ 2014-12-31 6:01 UTC (permalink / raw)
To: Vijay Rai
Cc: Poonam Aggrwal, gregkh, linux-kernel, linux-serial, Priyanka Jain,
linuxppc-dev
In-Reply-To: <1419932288-17562-1-git-send-email-vijay.rai@freescale.com>
On Tue, 2014-12-30 at 15:08 +0530, Vijay Rai wrote:
> Some of FSL SoCs like T1040 has new version of UART controller which
> can support 64byte FiFo.
> To enable 64 byte support, following needs to be done:
> -FCR[EN64] needs to be programmed to 1 to enable it.
> -Also, when FCR[EN64]==1, RTL bits to be used as below
> to define various Receive Trigger Levels:
> -FCR[RTL] = 00 1 byte
> -FCR[RTL] = 01 16 bytes
> -FCR[RTL] = 10 32 bytes
> -FCR[RTL] = 11 56 bytes
> -tx_loadsz is set to 32-bytes instead of 64-bytes to implement
> workaround of errata A-008006 which states that tx_loadsz should
> be configured less than Maximum supported fifo bytes
Why 32 and not 63?
> Signed-off-by: Vijay Rai <vijay.rai@freescale.com>
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> ---
> drivers/tty/serial/8250/8250_core.c | 20 +++++++++++++++++++-
> include/uapi/linux/serial_core.h | 3 ++-
> include/uapi/linux/serial_reg.h | 3 ++-
> 3 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index 11c6685..565748c 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -329,6 +329,14 @@ static const struct serial8250_config uart_config[] = {
> .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
> .flags = UART_CAP_FIFO | UART_CAP_AFE,
> },
> + [PORT_16550A_FSL64] = {
> + .name = "16550A_FSL64",
> + .fifo_size = 64,
> + .tx_loadsz = 32,
Put a comment here mentioning the erratum.
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index c172180..a3b4491 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -55,7 +55,8 @@
> #define PORT_ALTR_16550_F64 27 /* Altera 16550 UART with 64 FIFOs */
> #define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
> #define PORT_RT2880 29 /* Ralink RT2880 internal UART */
> -#define PORT_MAX_8250 29 /* max port ID */
> +#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
> +#define PORT_MAX_8250 31 /* max port ID */
Why are you adding 2 to PORT_MAX_8250 when you only add one new type?
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info
From: Alan Modra @ 2014-12-31 12:24 UTC (permalink / raw)
To: Anton Blanchard
Cc: Alexander Graf, ulrich.weigand, paulus, Scott Wood, linuxppc-dev
In-Reply-To: <20141218172546.432de7f2@kryten>
On Thu, Dec 18, 2014 at 05:25:46PM +1100, Anton Blanchard wrote:
> On Thu, 18 Dec 2014 16:11:54 +1100
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> > On Wed, 2014-12-17 at 02:16 +0100, Alexander Graf wrote:
> > > On 31.10.14 04:47, Anton Blanchard wrote:
> > > > LLVM doesn't support local named register variables and is
> > > > unlikely to. current_thread_info is using one, fix it by moving
> > > > it out and calling it __current_r1().
> > > >
> > > > I gave it a bit of an obscure name because we don't want anyone
> > > > else using it - they should use current_stack_pointer(). This
> > > > specific case is performance critical and we can't afford to call
> > > > a function to get it. Furthermore it isn't important to know
> > > > exactly where in the stack we are since we mask the lower bits.
> > > >
> > > > Signed-off-by: Anton Blanchard <anton@samba.org>
> > >
> > > Git bisect managed to point me to this commit as the offender for
> > > OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
> > >
> > > Doing a git revert of this commit on top of linus/master makes
> > > things work fine for me again.
> > >
> > >
> > > Alex
> > >
> > > Oops: Kernel access of bad area, sig: 11 [#2]
> > > SMP NR_CPUS=16 CoreNet Generic
> > > Modules linked in:
> > > CPU: 1 PID: 339 Comm: kworker/1:1 Tainted: G D
> > > 3.18.0-09423-g988adfd #1
> > > Workqueue: rpciod .rpc_async_schedule
> > > task: c0000001f6397500 ti: c0000001f6638000 task.ti:
> > > c0000001f6638000 NIP: c0000000004817a4 LR: c0000000004817a4 CTR:
> > > 0000000000000000 REGS: c0000001f663b0e0 TRAP: 0300 Tainted:
> > > G D (3.18.0-09423-g988adfd)
> > > MSR: 0000000080029000 <CE,EE,ME> CR: 24ad2e42 XER: 00000000
> > > DEAR: 202031303438355f ESR: 0000000000000000 SOFTE: 1
> > = r9 + 40
> >
> > > GPR00: c0000000004817a4 c0000001f663b360 c000000000988028
> > > 000000007f24333d GPR04: 5ff5738c1f2ebfb1 0000000000000000
> > > 0000000000000000 00000000000008f8 GPR08: c000000000480ae8
> > > 2020313034383537 36204b4220617320 6469726563740a31 GPR12:
> > > 3937302d30312d30 c00000000fff8780 c00000000007f988 c0000001f64c1600
> >
> > GPRs 9-12 say: " 1048576 KB as direct\n1970-01-0"
> >
> > Which is rarely a good sign :)
> >
> > Looks like it might be part of your dmesg from setup_page_sizes().
> >
> > > GPR16: 0000000000000000 0000000000000000 0000000000000000
> > > 00000000000005dc GPR20: c0000000009b8028 c00000007e034200
> > > 0000000000000548 c000000000000000 GPR24: c0000001f663b4b0
> > > 00000000b225831e 0000000000000000 0000000000000080 GPR28:
> > > 0000000000000548 00000000000008f8 0000000000000548 0000000000000094
> > > NIP [c0000000004817a4] .__skb_checksum+0x194/0x378 LR
> > > [c0000000004817a4] .__skb_checksum+0x194/0x378 Call Trace:
> > > [c0000001f663b360] [c0000000004817a4] .__skb_checksum+0x194/0x378
> > > (unreliable)
> > > [c0000001f663b440] [c0000000004819b4] .skb_checksum+0x2c/0x3c
> > > [c0000001f663b4c0] [c0000000004fd0a8] .udp4_hwcsum+0xa8/0x16c
> > > [c0000001f663b560] [c0000000004fd440] .udp_send_skb+0x2d4/0x370
> > > [c0000001f663b600]
> > > [c0000000004fd51c] .udp_push_pending_frames+0x40/0x94
> > > [c0000001f663b680] [c0000000004fec08] .udp_sendpage+0x150/0x1b4
> > > [c0000001f663b770] [c00000000050ae54] .inet_sendpage+0xa0/0x120
> > > [c0000001f663b810] [c00000000059c8cc] .xs_sendpages+0x2d0/0x30c
> > > [c0000001f663b8d0]
> > > [c00000000059cae4] .xs_udp_send_request+0x58/0x120
> > > [c0000001f663b970] [c000000000598f04] .xprt_transmit+0x80/0x36c
> > > [c0000001f663ba20] [c0000000005942d8] .call_transmit+0x19c/0x254
> > > [c0000001f663bab0] [c00000000059ff64] .__rpc_execute+0xbc/0x3c0
> > > [c0000001f663bb90] [c0000000000797f8] .process_one_work+0x1c0/0x474
> > > [c0000001f663bc40] [c00000000007a518] .worker_thread+0x17c/0x54c
> > > [c0000001f663bd30] [c00000000007fa8c] .kthread+0x104/0x124
> > > [c0000001f663be30]
> > > [c000000000000884] .ret_from_kernel_thread+0x58/0xd4 Instruction
> > > dump: 7d1f3a14 7c6a1850 e9580000 7fbd4050 786334e4 e90a0000
> > > 7c63ba14 f8490028 7c63ea14 7d0903a6 e84a0008 4e800421 <e8490028>
> > > 7c641b78 78270464 e9580008
> >
> > Which is:
> >
> > add r8, r31, r7
> > subf r3, r10, r3
> > ld r10, 0(r24)
> > subf r29, r29, r8
> > rldicr r3, r3, 6, 51
> > ld r8, 0(r10)
> > add r3, r3, r23
> > std r2, 40(r9)
> > add r3, r3, r29
> > mtctr r8
> > ld r2, 8(r10)
> > bctrl
> > ld r2, 40(r9) <---
> > mr r4, r3
> > rldicr r7, r1, 0, 49
> > ld r10, 8(r24)
> >
> >
> > Which looks a bit odd. I'd expect us to be saving/restoring r2 to the
> > stack, though maybe r9 was pointing at the stack?
>
> Nice catch! This looks like a compiler bug.
Yes, it is.
> > Looking at your vmlinux.broken I don't see the same code gen.
>
> For whatever reason we ended up with r10 this time:
>
> 7c 2a 0b 78 mr r10,r1
> ...
> f8 4a 00 28 std r2,40(r10)
> 7c 63 ba 14 add r3,r3,r23
> 7c e9 03 a6 mtctr r7
> 7c 63 ea 14 add r3,r3,r29
> 38 a0 00 00 li r5,0
> e8 48 00 08 ld r2,8(r8)
> 4e 80 04 21 bctrl
> e8 4a 00 28 ld r2,40(r10)
>
> The indirect function call is allowed to clobber r10, gcc is doing
> something very wrong here.
Right. This is really an rs6000 backend bug. We describe one of the
indirect calls that go wrong here as
(call_insn 108 107 109 13 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (reg:DI 288) [0 *_67 S4 A8])
(const_int 64 [0x40])))
(use (mem:DI (plus:DI (reg/f:DI 287 [ ops_44(D)->update ])
(const_int 8 [0x8])) [0 S8 A8]))
(set (reg:DI 2 2)
(mem/v/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 40 [0x28])) [0 S8 A8]))
(clobber (reg:DI 65 lr))
]) net/core/skbuff.c:2085 680 {*call_value_indirect_aixdi}
<notes and arg uses omitted for clarity>
)
Notice that the RTL contains a "parallel". As you might guess, gcc
treats the vector of expressions inside the square brackets of the
parallel as happening "in parallel". Meaning that as far as gcc is
concerned the toc restore part (third element) happens at the same
time as the call (first element). So if gcc replaces (reg:DI 1) in
the toc restore with some other register known to have the same value
*before* the call, gcc's RTL analysis will conclude that such a
replacement is valid.
That's what happens in the cprop1 pass. The rtl dump shows
LOCAL COPY-PROP: Replacing reg 1 in insn 108 with reg 203
and then it's a matter of luck just what hard register is allocated to
pseudo-reg 203.
Of course, replacing r1 with some other register is a completely
useless thing to do, but trying to tell gcc that in our particular
case we want this generic optimisation disabled isn't so easy. (Well,
it's dead easy if you want to hack cprop.c:do_local_cprop, just rip
out
|| (GET_CODE (PATTERN (insn)) != USE
&& asm_noperands (PATTERN (insn)) < 0)))
but maybe not so easy to get such patches committed..) Instead, the
way I'd go about fixing this is removing the r1 reference in our toc
save/restore RTL, ie. don't use a mem, use an unspec.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
From: Paul E. McKenney @ 2014-12-31 13:19 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Heiko Carstens, Tiejun Chen, Paul Mackerras, Daniel Walter,
Ingo Molnar, open list:S390, Vincent Guittot,
Christian Borntraeger, Jens Freimann, Pranith Kumar,
Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Anton Blanchard,
Scott Wood, Lai Jiangshan, Li Zhong, Nishanth Aravamudan,
open list, Srivatsa S. Bhat, Martin Schwidefsky, supporter:S390,
open list:LINUX FOR POWERPC...
In-Reply-To: <20141230190740.GC23965@worktop.programming.kicks-ass.net>
On Tue, Dec 30, 2014 at 08:07:40PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 30, 2014 at 01:54:07PM -0500, Pranith Kumar wrote:
> > On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
> > >> Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
> > >> is a compile time failure if srcu is used when not enabled. This was decided to
> > >> be better than waiting until link time for a failure to occur.
> > >
> > > Why?
> >
> > This is part of the kernel tinification efforts. The first patch was
> > posted here: https://lkml.org/lkml/2014/12/4/848. This patch enables a
> > compile time failure instead of a link time failure.
>
> can't be arsed to click. again, why does it matter when it fails,
> neither stages produces a working kernel so tinification cannot be the
> purpose.
In fairness, Pranith's original submission did force the failure at
link time. One piece of feedback was to force the failure at compile
time (can't remember from who). But given the hassles encountered with
compile-time failure, it might well be getting to the point where it is
time to fall back to the link-time-failure approach.
Thanx, Paul
^ permalink raw reply
* Re: [V6,1/9] elf: Add new powerpc specifc core note sections
From: Anshuman Khandual @ 2015-01-01 8:08 UTC (permalink / raw)
To: Edjunior Barbosa Machado, Michael Ellerman, linux-kernel,
linuxppc-dev
Cc: mikey, james.hogan, avagin, Paul.Clothier, peterz, palves,
Ulrich Weigand, shuahkh, akpm, oleg, dhowells, kirjanov, davej,
tglx, sukadev, davem, sam.bobroff
In-Reply-To: <54947C64.4030206@linux.vnet.ibm.com>
On 12/20/2014 12:58 AM, Edjunior Barbosa Machado wrote:
> On 12/08/2014 08:08 AM, Anshuman Khandual wrote:
>> On 12/03/2014 12:18 PM, Anshuman Khandual wrote:
>>> On 12/03/2014 10:52 AM, Michael Ellerman wrote:
>>>> On Tue, 2014-02-12 at 07:56:45 UTC, Anshuman Khandual wrote:
>>>>> This patch adds four new ELF core note sections for powerpc
>>>>> transactional memory and one new ELF core note section for
>>>>> powerpc general miscellaneous debug registers. These addition
>>>>> of new ELF core note sections extends the existing ELF ABI
>>>>> without affecting it in any manner.
>>>>>
>>>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>>> ---
>>>>> include/uapi/linux/elf.h | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
>>>>> index ea9bf25..2260fc0 100644
>>>>> --- a/include/uapi/linux/elf.h
>>>>> +++ b/include/uapi/linux/elf.h
>>>>> @@ -379,6 +379,11 @@ typedef struct elf64_shdr {
>>>>> #define NT_PPC_VMX 0x100 /* PowerPC Altivec/VMX registers */
>>>>> #define NT_PPC_SPE 0x101 /* PowerPC SPE/EVR registers */
>>>>> #define NT_PPC_VSX 0x102 /* PowerPC VSX registers */
>>>>> +#define NT_PPC_TM_SPR 0x103 /* PowerPC TM special registers */
>>>>> +#define NT_PPC_TM_CGPR 0x104 /* PowerpC TM checkpointed GPR */
>>>>> +#define NT_PPC_TM_CFPR 0x105 /* PowerPC TM checkpointed FPR */
>>>>> +#define NT_PPC_TM_CVMX 0x106 /* PowerPC TM checkpointed VMX */
>>>>> +#define NT_PPC_MISC 0x107 /* PowerPC miscellaneous registers */
>>>>
>>>> This is a really terrible name, "MISC".
>>>>
>>>> Having said that, I guess it's accurate. We have a whole bunch of regs that
>>>> have accrued over recent years that aren't accessible via ptrace.
>>>>
>>>> It seems to me if we're adding a misc regset we should be adding everything we
>>>> might want to it that is currenty architected.
>>>
>>> But I believe they also need to be part of the thread_struct structure to be
>>> accessible from ptrace.
>>
>> Currently we dont context save/restore the PMC count registers (PMC1-PMC6)
>> during the process context switch. So the values of PMC1..PMC6 are not
>> thread specific in the structure. To be able to access them in ptrace
>> when the tracee has stopped, we need to context save these counters
>> in the thread struct. Shall we do that ? Then we can add them to the
>> MISC regset bucket irrespective of whats the value we get in there when
>> we probe through ptrace.
>>
>> The same goes for MMCRA, CFAR registers as well.
>>
>>>
>>>>
>>>> But currently you only include the PPR, TAR & DSCR.
>>>
>>> Yeah, thats what we started with.
>>>
>>>>
>>>> Looking at Power ISA v2.07, I see the following that could be included:
>>>>
>>>> MMCR2
>>>> MMCRA
>>>> PMC1
>>>> PMC2
>>>> PMC3
>>>> PMC4
>>>> PMC5
>>>> PMC6
>>>> MMCR0
>>>> EBBHR
>>>> EBBRR
>>>> BESCR
>>>> SIAR
>>>> SDAR
>>>> CFAR?
>>>
>>> MMCRA, PMC[1..6], EBBHR, BESCR, EBBRR, CFAR are not part of the thread struct.
>>
>> Sorry. EBBRR, EBBHR, BESCR registers are part of the thread struct.
>>
>>>
>>>>
>>>> Those are all new in 2.07 except for CFAR.
>>>>
>>>> There might be more I missed, that was just a quick scan.
>>>>
>>>> Some are only accessible when EBB is in use, maybe those could be a separate
>>>> regset.
>>>
>>> Yeah we can have one more regset for EBB specific registers.
>>
>> Should the new EBB specific regset include only EBBRR, EBBHR, BESCR registers
>> or should it also include SIAR, SDAR, SIER, MMCR0, MMCR2 registers as well. I
>> was thinking about putting these five registers into the MISC bucket instead.
>> But from the perf code, it looks like these five registers are also related to
>> the EBB context as well.
>>
>> Some clarity on these points would really help.
>
> Hi,
>
> from the provided testcase using ptrace interface, reviewing with the help
> of Ulrich, it looks OK from GDB perspective, with the exception of a few
> concerns:
>
> The patchset seems to change the "original" ptrace requests (i.e.
> PTRACE_GETREGS/GETFPREGS/GETVRREGS...) to return the "transactional" state, and
> adds new register sets to return the "checkpointed" state. Considering that
> whenever you get a debugger interception inside a transactional block, the
> transaction will abort, we're wondering if it wouldn't make more sense to
> display the 'checkpointed' state as the normal registers since this is where the
> execution will continue from.
Debugger interception (trace interrupt) in between any transaction block will abort
it ? I doubt that. The tracee process will just stop, it's context gets saved in the
kernel so that it can again start executing from the exact same point onward when it
resumes. If this happens when inside any transaction block, the transaction's running
context and check pointed context will get saved. The execution will again start from
the running context values instead of check pointed when the process resumes. Check
pointed values will be loaded back into the context when the transaction finishes.
Inside transaction both running and check pointed values can be probed independently.
>
> Also, we've noticed that the 'misc' regset contains registers from different ISA
> versions (dscr and ppr appear in ISA 2.05, tar is from 2.07). I'm not sure if
> there is a way to detect presence/validity of such registers, but perhaps it
> might be a good idea to separate registers from different ISAs in different
> regsets.
Thats right, will use feature CPU_FTR_ARCH_207S (which checks whether we are v2.07
compliant) to detect whether TAR register is available or not.
>
> Regarding the inclusion of other registers along with the EBB-related ones, I'm
> sorry but I'm not familiar with them.
Michael Ellerman mentioned that we can look into them separately sometime later
not in this patch series.
^ 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