[RFC PATCH] security: Add a config option to disable security mitigations
Instead of having to pass 'mitigations=off' on the kernel command line,
add a config option that has a similar effect.
Adding this makes it easier to disable mitigations in scenarios where
you cannot modify the command line or are unable to pass a command line
while booting.
Signed-off-by: Pranith Kumar
---
kernel/cpu.c | 2 +-
security/Kconfig | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6ff2578ecf17..584eb39585d6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2542,7 +2542,7 @@ early_param("mitigations", mitigations_parse_cmdline);
/* mitigations=off */
bool cpu_mitigations_off(void)
{
- return cpu_mitigations == CPU_MITIGATIONS_OFF;
+ return cpu_mitigations == CPU_MITIGATIONS_OFF ||
IS_ENABLED(CONFIG_DISABLE_MITIGATIONS);
}
EXPORT_SYMBOL_GPL(cpu_mitigations_off);
diff --git a/security/Kconfig b/security/Kconfig
index cd3cc7da3a55..90b8e9c89a6d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -65,6 +65,14 @@ config PAGE_TABLE_ISOLATION
See Documentation/x86/pti.rst for more details.
+config DISABLE_MITIGATIONS
+ bool "Disable kernel security mitigations"
+ default n
+ help
+ This turns off the kernel security mitigations. This is
+ equivalent to passing 'mitigations=off' on the kernel
+ command line.
+
config SECURITY_INFINIBAND
bool "Infiniband Security Hooks"
depends on SECURITY && INFINIBAND
--
2.27.0
Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee
Hi Paul, On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney wrote: > Recent memory-model work deduces the relationships of RCU read-side > critical sections and grace periods based on the relationships of > accesses within a critical section and accesses preceding and following > the grace period. This commit therefore adds this viewpoint. > > Signed-off-by: Paul E. McKenney > --- > .../RCU/Design/Requirements/Requirements.html | 25 > +- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html > b/Documentation/RCU/Design/Requirements/Requirements.html > index a4d3838130e4..81b40cb83435 100644 > --- a/Documentation/RCU/Design/Requirements/Requirements.html > +++ b/Documentation/RCU/Design/Requirements/Requirements.html > @@ -547,7 +547,7 @@ The rcu_access_pointer() on line 6 is > similar to > It could reuse a value formerly fetched from this same pointer. > It could also fetch the pointer from gp in a byte-at-a-time > manner, resulting in load tearing, in turn resulting a bytewise > - mash-up of two distince pointer values. > + mash-up of two distinct pointer values. > It might even use value-speculation optimizations, where it makes > a wrong guess, but by the time it gets around to checking the > value, an update has changed the pointer to match the wrong guess. > @@ -659,6 +659,29 @@ systems with more than one CPU: > In other words, a given instance of synchronize_rcu() > can avoid waiting on a given RCU read-side critical section only > if it can prove that synchronize_rcu() started first. > + > + > + A related question is “When rcu_read_lock() > + doesn't generate any code, why does it matter how it relates > + to a grace period?” > + The answer if that it is not the relationship of s/if/is? > + rcu_read_lock() itself that is important, but rather > + the relationship of the code within the enclosed RCU read-side > + critical section to the code preceding and following the > + grace period. > + If we take this viewpoint, then a given RCU read-side critical > + section begins before a given grace period when some access > + preceding the grace period observes the effect of some access > + within the critical section, in which case none of the accesses > + within the critical section may observe the effects of any > + access following the grace period. > + > + > + As of late 2016, mathematical models of RCU take this > + viewpoint, for example, see slides 62 and 63 > + of the > +href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf";>2016 > LinuxCon EU > + presentation. > > > > -- > 2.5.2 > -- Pranith
[PATCH] Documentation/RCU: Fix minor typo
deference should actually be dereference. Signed-off-by: Pranith Kumar --- Documentation/RCU/whatisRCU.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 2044227..5cbd8b2 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -237,7 +237,7 @@ rcu_dereference() The reader uses rcu_dereference() to fetch an RCU-protected pointer, which returns a value that may then be safely - dereferenced. Note that rcu_deference() does not actually + dereferenced. Note that rcu_dereference() does not actually dereference the pointer, instead, it protects the pointer for later dereferencing. It also executes any needed memory-barrier instructions for a given CPU architecture. Currently, only Alpha -- 2.10.1
[PATCH] scsi: Remove unnecessary comparison
val is an unsigned int which makes the comparison >=0 unnecessary. This patch removes it. Signed-off-by: Pranith Kumar --- drivers/scsi/sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index d3e852a..7a919b2 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -314,7 +314,7 @@ protection_type_store(struct device *dev, struct device_attribute *attr, if (err) return err; - if (val >= 0 && val <= SD_DIF_TYPE3_PROTECTION) + if (val <= SD_DIF_TYPE3_PROTECTION) sdkp->protection_type = val; return count; -- 2.9.2
Re: [PATCH tip/core/rcu 04/12] rcu: Move expedited code from tree.c to tree_exp.h
Hi Paul, On Wed, Jun 15, 2016 at 5:46 PM, Paul E. McKenney wrote: > People have been having some difficulty finding their way around the > RCU code. This commit therefore pulls some of the expedited grace-period > code from tree.c to a new tree_exp.h file. This commit is strictly code > movement, with the exception of a forward declaration that was added > for the sync_sched_exp_online_cleanup() function. > > A subsequent commit will move the remaining expedited grace-period code > from tree_plugin.h to tree_exp.h. > > Signed-off-by: Paul E. McKenney > --- > kernel/rcu/tree.c | 545 +--- > kernel/rcu/tree_exp.h | 564 > ++ > 2 files changed, 566 insertions(+), 543 deletions(-) > create mode 100644 kernel/rcu/tree_exp.h > I've always wondered why you chose to only have a header file instead of the traditional x.h/x.c split for declarations and definitions(looking at tree_plugin.h). Is there any particular reason for this? Thanks, -- Pranith
Re: [PATCH] kvm: Fix build error caused by redefinition
Hi Paolo, Paolo Bonzini writes: > > Please test this instead: This patch works for me. Please feel free to add: Tested-by: Pranith Kumar > > diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile > index 7f7b6d86ac73..eba0bea6e032 100644 > --- a/arch/powerpc/kvm/Makefile > +++ b/arch/powerpc/kvm/Makefile > @@ -8,7 +8,8 @@ ccflags-y := -Ivirt/kvm -Iarch/powerpc/kvm > KVM := ../../../virt/kvm > > common-objs-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o \ > - $(KVM)/eventfd.o $(KVM)/vfio.o > + $(KVM)/eventfd.o > +common-objs-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o > > CFLAGS_e500_mmu.o := -I. > CFLAGS_e500_mmu_host.o := -I. > > > Paolo -- Pranith
[PATCH] kvm: Fix build error caused by redefinition
Build on 32-bit PPC fails with the following error:
int kvm_vfio_ops_init(void)
^
In file included from arch/powerpc/kvm/../../../virt/kvm/vfio.c:21:0:
arch/powerpc/kvm/../../../virt/kvm/vfio.h:8:90: note: previous definition of
‘kvm_vfio_ops_init’ was here
arch/powerpc/kvm/../../../virt/kvm/vfio.c:292:6: error: redefinition of
‘kvm_vfio_ops_exit’
void kvm_vfio_ops_exit(void)
^
In file included from arch/powerpc/kvm/../../../virt/kvm/vfio.c:21:0:
arch/powerpc/kvm/../../../virt/kvm/vfio.h:12:91: note: previous definition of
‘kvm_vfio_ops_exit’ was here
scripts/Makefile.build:258: recipe for target
'arch/powerpc/kvm/../../../virt/kvm/vfio.o' failed
make[3]: *** [arch/powerpc/kvm/../../../virt/kvm/vfio.o] Error 1
Fix it by enclosing the definitions within CONFIG_KVM_VFIO
Signed-off-by: Pranith Kumar
---
virt/kvm/vfio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 1dd087d..201293b 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -284,6 +284,7 @@ static int kvm_vfio_create(struct kvm_device *dev, u32 type)
return 0;
}
+#ifdef CONFIG_KVM_VFIO
int kvm_vfio_ops_init(void)
{
return kvm_register_device_ops(&kvm_vfio_ops, KVM_DEV_TYPE_VFIO);
@@ -293,3 +294,4 @@ void kvm_vfio_ops_exit(void)
{
kvm_unregister_device_ops(KVM_DEV_TYPE_VFIO);
}
+#endif
--
2.7.0
Re: [PATCH] init: print warning message if /dev/console failed to open
Hello Alexander,
On Wed, Feb 3, 2016 at 1:58 PM, Alexander Kuleshov wrote:
> Signed-off-by: Alexander Kuleshov
Please describe the changes in each patch. Why do you need this warning?
If you haven't read it yet, please read (esp. Section 2):
https://www.kernel.org/doc/Documentation/SubmittingPatches
> ---
> init/do_mounts.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index dea5de9..ca5da05 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -505,7 +505,9 @@ void __init change_floppy(char *fmt, ...)
> termios.c_lflag |= ICANON;
> sys_ioctl(fd, TCSETSF, (long)&termios);
> sys_close(fd);
> - }
> + } else
> + pr_err("Warning: unable to open /dev/console.\n");
Your message says 'Warning'. But you use pr_err(). I think pr_warn()
might be a better option.
> +
> }
> #endif
>
> --
> 2.7.0.25.gfc10eb5
>
Thanks,
--
Pranith
Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers
On Tue, Jan 26, 2016 at 12:45 AM, Pranith Kumar wrote: > On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman > wrote: >> On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote: >> >>> In 4.5-rc1, I am getting a build failure as follows: >>> >>> mm/memory.c: In function ‘do_swap_page’: >>> mm/memory.c:2573:9: error: implicit declaration of function >>> ‘pte_mksoft_dirty’ >>> [-Werror=implicit-function-declaration] >>>pte = pte_mksoft_dirty(pte); >>> >>> The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in >>> arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch. >>> >>> Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system. >> >> It's building for me, what config are you using? >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/12597204/ >> Found the original config file too. Please find it attached here. -- Pranith config-failure-2 Description: Binary data
qemu fails to build on 4.5-rc1
Hi Dave,
Commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to
FS_IOC_FS[SG]ETXATTR promotion") breaks building latest qemu as
follows:
In file included from /usr/include/xfs/xfs.h:58:0,
from /home/pranith/qemu/block/raw-posix.c:96:
/usr/include/xfs/xfs_fs.h:42:8: error: redefinition of ‘struct fsxattr’
struct fsxattr {
^
In file included from /home/pranith/qemu/block/raw-posix.c:59:0:
/usr/include/linux/fs.h:155:8: note: originally defined here
struct fsxattr {
^
/home/pranith/qemu/rules.mak:57: recipe for target 'block/raw-posix.o' failed
I think this is caused by moving the fsxattr struct around. Any
suggestion on how to fix this?
Thanks,
--
Pranith
Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers
On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman wrote: > On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote: > >> In 4.5-rc1, I am getting a build failure as follows: >> >> mm/memory.c: In function ‘do_swap_page’: >> mm/memory.c:2573:9: error: implicit declaration of function >> ‘pte_mksoft_dirty’ >> [-Werror=implicit-function-declaration] >>pte = pte_mksoft_dirty(pte); >> >> The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in >> arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch. >> >> Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system. > > It's building for me, what config are you using? > > http://kisskb.ellerman.id.au/kisskb/buildresult/12597204/ > I am not sure where I messed up, but I am getting the following error now. Config attached. The same patch fixes this error. In file included from fs/proc/task_mmu.c:14:0: include/linux/swapops.h: In function ‘pte_to_swp_entry’: include/linux/swapops.h:69:6: error: implicit declaration of function ‘pte_swp_soft_dirty’ [-Werror=implicit-function-declaration] if (pte_swp_soft_dirty(pte)) ^ include/linux/swapops.h:70:9: error: implicit declaration of function ‘pte_swp_clear_soft_dirty’ [-Werror=implicit-function-declaration] pte = pte_swp_clear_soft_dirty(pte); ^ fs/proc/task_mmu.c: In function ‘clear_soft_dirty’: fs/proc/task_mmu.c:876:11: error: implicit declaration of function ‘pte_clear_soft_dirty’ [-Werror=implicit-function-declaration] ptent = pte_clear_soft_dirty(ptent); ^ fs/proc/task_mmu.c: In function ‘pte_to_pagemap_entry’: fs/proc/task_mmu.c:1158:7: error: implicit declaration of function ‘pte_soft_dirty’ [-Werror=implicit-function-declaration] if (pte_soft_dirty(pte)) ^ cc1: some warnings being treated as errors -- Pranith config-failure Description: Binary data
[RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers
In 4.5-rc1, I am getting a build failure as follows: mm/memory.c: In function ‘do_swap_page’: mm/memory.c:2573:9: error: implicit declaration of function ‘pte_mksoft_dirty’ [-Werror=implicit-function-declaration] pte = pte_mksoft_dirty(pte); The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch. Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system. Signed-off-by: Pranith Kumar --- arch/powerpc/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e4824fd..21cb5c5 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -557,7 +557,7 @@ choice config PPC_4K_PAGES bool "4k page size" - select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S + select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S && PPC64 config PPC_16K_PAGES bool "16k page size" @@ -566,7 +566,7 @@ config PPC_16K_PAGES config PPC_64K_PAGES bool "64k page size" depends on !PPC_FSL_BOOK3E && (44x || PPC_STD_MMU_64 || PPC_BOOK3E_64) - select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S + select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S && PPC64 config PPC_256K_PAGES bool "256k page size" -- 2.7.0
[PATCH] llist: Use for() initializer and conditional
Simplify the code a bit by using the initializer and conditional
check in for() instead of a separate if() statement in the loop.
Signed-off-by: Pranith Kumar
---
lib/llist.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lib/llist.c b/lib/llist.c
index ae5872b..ddbeebb 100644
--- a/lib/llist.c
+++ b/lib/llist.c
@@ -66,10 +66,7 @@ struct llist_node *llist_del_first(struct llist_head *head)
{
struct llist_node *entry, *old_entry, *next;
- entry = smp_load_acquire(&head->first);
- for (;;) {
- if (entry == NULL)
- return NULL;
+ for (entry = smp_load_acquire(&head->first); entry ; ) {
old_entry = entry;
next = READ_ONCE(entry->next);
entry = cmpxchg(&head->first, old_entry, next);
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] llist: Use for conditional in llist_del_first()
Simplify the code a bit by using the initializer and conditional
check in for() instead of a separate if() statement in the loop.
Signed-off-by: Pranith Kumar
---
lib/llist.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lib/llist.c b/lib/llist.c
index 0b0e977..03d7aad 100644
--- a/lib/llist.c
+++ b/lib/llist.c
@@ -66,10 +66,7 @@ struct llist_node *llist_del_first(struct llist_head *head)
{
struct llist_node *entry, *old_entry, *next;
- entry = head->first;
- for (;;) {
- if (entry == NULL)
- return NULL;
+ for (entry = head->first; entry ;) {
old_entry = entry;
next = entry->next;
entry = cmpxchg(&head->first, old_entry, next);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )
On Mon, Oct 12, 2015 at 1:04 AM, Jim Davis wrote: > On Sun, Oct 11, 2015 at 7:58 PM, Pranith Kumar > wrote: >> >> >> ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such >> file or directory >> scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed >> make[1]: *** [bindeb-pkg] Error 2 >> Makefile:1226: recipe for target 'bindeb-pkg' failed >> make: *** [bindeb-pkg] Error 2 > > So this is a build on a ppc system? What's the distro? I've checked > that bindeb-pkg works fine with 4.3-rc4 on Ubuntu 15.04 with the amd64 > architecture, but that's probably not much consolation. > I am running Debian Jessie. Apparently the fix has been posted. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )
Hi Michal, On Tue, Sep 8, 2015 at 11:38 AM, Michal Marek wrote: > Hi Linus, > > these are the non-core kbuild changes for 4.3-rc1: > - deb-pkg: > + module signing fix > + dtb files are added to the package > + do not require `hostname -f` to work during build > + make deb-pkg generates a source package, bindeb-pkg has been added > to only generate the binary package It would have been great to not change the functionality of the target. Instead you could have added srcdeb-pkg to generate both the source and binary. Other than that, I keep seeing these errors now: dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-firmware-image-4.3.0-rc4+' in `../linux-firmware-image-4.3.0-rc4+_4.3.0-rc4+-8_powerpc.deb'. dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-headers-4.3.0-rc4+' in `../linux-headers-4.3.0-rc4+_4.3.0-rc4+-8_powerpc.deb'. dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-libc-dev' in `../linux-libc-dev_4.3.0-rc4+-8_powerpc.deb'. dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-image-4.3.0-rc4+' in `../linux-image-4.3.0-rc4+_4.3.0-rc4+-8_powerpc.deb'. dpkg-genchanges: warning: package linux-image-4.3.0-rc4 listed in files list but not in control info dpkg-genchanges: warning: package linux-firmware-image-4.3.0-rc4 listed in files list but not in control info dpkg-genchanges: warning: package linux-headers-4.3.0-rc4 listed in files list but not in control info dpkg-genchanges: binary-only upload (no source code included) Use of uninitialized value $b in string eq at /usr/share/perl5/Dpkg/Arch.pm line 399. Use of uninitialized value $arch in pattern match (m//) at /usr/share/perl5/Dpkg/Arch.pm line 335. Use of uninitialized value $arch in hash element at /usr/share/perl5/Dpkg/Arch.pm line 340. dpkg-genchanges: error: cannot fstat file ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such file or directory scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed make[1]: *** [bindeb-pkg] Error 2 Makefile:1226: recipe for target 'bindeb-pkg' failed make: *** [bindeb-pkg] Error 2 Any idea on how to fix this? Thanks, Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] doc: Clarify that nmi_watchdog param is for hardlockups
The kernel NMI watchdog acts as both a hardlockup and softlockup detector. However, the kernel parameter nmi_watchdog can only enable or disable the hardlockup detector. Clarify that in the documentation. Signed-off-by: Pranith Kumar --- Documentation/kernel-parameters.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6fecc72..5b83279 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2329,11 +2329,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels Format: [panic,][nopanic,][num] Valid num: 0 or 1 - 0 - turn nmi_watchdog off - 1 - turn nmi_watchdog on + 0 - turn hardlockup detector in nmi_watchdog off + 1 - turn hardlockup detector in nmi_watchdog on When panic is specified, panic when an NMI watchdog timeout occurs (or 'nopanic' to override the opposite - default). + default). To disable both hard and soft lockup detectors, + please see 'nowatchdog'. This is useful when you use a panic=... timeout and need the box quickly up again. -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: cmpxchg_double: Add missing memory clobber
On Tue, Oct 6, 2015 at 4:16 PM, H. Peter Anvin wrote: > > NAK. We already have the "+m" for exactly this reason; adding an > explicit memory clobber should only be used to prevent movement of > *other* memory operations around this one (i.e. a barrier). > OK. If that is so, can you please explain why we need it in the __raw_cmpxchg() case? I think it is a good idea to make cmpxchg() and cmpxchg_double() have similar barrier semantics. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: cmpxchg_double: Add missing memory clobber
We are reading from memory locations pointed to by p1 and p2 in the asm block. Add a memory clobber flag to make gcc aware of this. Signed-off-by: Pranith Kumar --- arch/x86/include/asm/cmpxchg.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cmpxchg.h b/arch/x86/include/asm/cmpxchg.h index 4a2e5bc..3e83949 100644 --- a/arch/x86/include/asm/cmpxchg.h +++ b/arch/x86/include/asm/cmpxchg.h @@ -214,7 +214,8 @@ extern void __add_wrong_size(void) : "=a" (__ret), "+d" (__old2), \ "+m" (*(p1)), "+m" (*(p2)) \ : "i" (2 * sizeof(long)), "a" (__old1),\ - "b" (__new1), "c" (__new2)); \ + "b" (__new1), "c" (__new2) \ +: "memory"); \ __ret; \ }) -- 2.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants
On Wed, Sep 2, 2015 at 11:23 AM, Pranith Kumar wrote: > Hi Will, > > On 09/02/2015 05:59 AM, Will Deacon wrote: >> I just thought it was worth making this point, because it is prohibited >> in SC and I don't want people to think that our RELEASE/ACQUIRE operations >> are SC (even though they happen to be on arm64). > > This is interesting information. Does that mean that the following patch > should work? (I am not proposing to use it, just trying to understand if > REL+ACQ will act as a full barrier on ARM64, which you say it does). > > Thanks, > Pranith. > > diff --git a/arch/arm64/include/asm/cmpxchg.h > b/arch/arm64/include/asm/cmpxchg.h > index d8c25b7..14a1b35 100644 > --- a/arch/arm64/include/asm/cmpxchg.h > +++ b/arch/arm64/include/asm/cmpxchg.h > @@ -68,8 +68,7 @@ static inline unsigned long __xchg(unsigned long x, > volatile void *ptr, int size > BUILD_BUG(); > } > > - smp_mb(); > - return ret; > + return smp_load_acquire(ret); I meant 'smp_load_acquire(&ret);' -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants
Hi Will, On 09/02/2015 05:59 AM, Will Deacon wrote: > I just thought it was worth making this point, because it is prohibited > in SC and I don't want people to think that our RELEASE/ACQUIRE operations > are SC (even though they happen to be on arm64). This is interesting information. Does that mean that the following patch should work? (I am not proposing to use it, just trying to understand if REL+ACQ will act as a full barrier on ARM64, which you say it does). Thanks, Pranith. diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h index d8c25b7..14a1b35 100644 --- a/arch/arm64/include/asm/cmpxchg.h +++ b/arch/arm64/include/asm/cmpxchg.h @@ -68,8 +68,7 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size BUILD_BUG(); } - smp_mb(); - return ret; + return smp_load_acquire(ret); } #define xchg(ptr,x) \ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: membarrier selftest issue
Hi Mathieu, On Mon, Jun 15, 2015 at 11:31 AM, Mathieu Desnoyers wrote: > Hi, > > The updated membarrier tree: > https://github.com/compudj/linux-dev > branch: sys-membarrier-volatile > > has an issue building selftests (make -C tools/testing/selftests) > > It appears that including linux/membarrier.h from those userspace > tests now fails (as of 4.1-rc8). Of course, my system does not have > the updated userspace headers installed. What is the right course > of action there ? > This somehow is working for me. Did you install the kernel? I am on debian and I had to install kernel+headers+libc for this to work. pmu tests did not work due to missing headers but membarrier and memfd did work. pranith@macmini:~/linux$ make -C tools/testing/selftests make: Entering directory '/home/pranith/linux/tools/testing/selftests' for TARGET in breakpoints cpu-hotplug efivarfs exec firmware ftrace kcmp membarrier memfd memory-hotplug mount mqueue net powerpc ptrace size sysctl timers user vm x86; do \ make -C $TARGET; \ done; make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/breakpoints' echo "Not an x86 target, can't build breakpoints selftests" Not an x86 target, can't build breakpoints selftests make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/breakpoints' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/cpu-hotplug' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/cpu-hotplug' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/efivarfs' gcc -Wallopen-unlink.c -o open-unlink gcc -Wallcreate-read.c -o create-read make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/efivarfs' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/exec' gcc -Wall -o execveat execveat.c ln -s -f execveat execveat.symlink cp execveat execveat.denatured chmod -x execveat.denatured echo '#!/bin/sh' > script echo 'exit $*' >> script chmod +x script mkdir -p subdir make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/exec' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/firmware' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/firmware' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/ftrace' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/ftrace' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/kcmp' gcc -I../../../../usr/include/kcmp_test.c -o kcmp_test make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/kcmp' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/membarrier' gcc -g -I../../../../usr/include/ membarrier_test.c -o membarrier_test make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/membarrier' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/memfd' gcc -D_FILE_OFFSET_BITS=64 -I../../../../include/uapi/ -I../../../../include/ -I../../../../usr/include/ memfd_test.c -o memfd_test make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/memfd' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/memory-hotplug' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/memory-hotplug' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/mount' gcc -Wall -O2 unprivileged-remount-test.c -o unprivileged-remount-test make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/mount' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/mqueue' gcc -O2 mq_open_tests.c -o mq_open_tests -lrt gcc -O2 -o mq_perf_tests mq_perf_tests.c -lrt -lpthread -lpopt mq_perf_tests.c:39:18: fatal error: popt.h: No such file or directory #include ^ compilation terminated. Makefile:4: recipe for target 'all' failed make[1]: *** [all] Error 1 make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/mqueue' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/net' gcc -Wall -O2 -g -I../../../../usr/include/ -o socket socket.c gcc -Wall -O2 -g -I../../../../usr/include/ -o psock_fanout psock_fanout.c gcc -Wall -O2 -g -I../../../../usr/include/ -o psock_tpacket psock_tpacket.c make[1]: Leaving directory '/home/pranith/linux/tools/testing/selftests/net' make[1]: Entering directory '/home/pranith/linux/tools/testing/selftests/powerpc' make -k -C pmu all make[2]: Entering directory '/home/pranith/linux/tools/testing/selftests/powerpc/pmu' gcc -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"v4.1-rc8-3-g9ab055c-dirty"' -I/home/pranith/linux/tools/testing/selftests/powerpc -m64 -o count_instructions loop.S count_instructions.c ../harness.c event.c lib.c In file included
Re: [PATCH] kernel:signal - Fix for typos in comments.
On Sat, May 23, 2015 at 1:09 AM, Shailendra Verma wrote: Please include a changelog for every patch you submit exolaining why you think the change makes sense. > > Signed-off-by: Shailendra Verma > --- > kernel/signal.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/signal.c b/kernel/signal.c > index d51c5dd..5c65e7c 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -342,7 +342,7 @@ static bool task_participate_group_stop(struct > task_struct *task) > sig->group_stop_count--; > > /* > -* Tell the caller to notify completion iff we are entering into a > +* Tell the caller to notify completion if we are entering into a iff means "if and only if" and I think it makes perfect sense here. I encourage you to keep trying :) Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro
On Wed, Apr 29, 2015 at 12:59 PM, Daniel Borkmann wrote: > On 04/29/2015 06:40 PM, Pranith Kumar wrote: >> >> On Wed, Apr 29, 2015 at 10:59 AM, mancha security >> wrote: >>> >>> >>> The problem is that ICC defines __GNUC__ so barrier() gets defined >>> in compiler-gcc.h. Your commit removed an #undef from compiler-intel.h >>> so compiler.h will never define barrier to __memory_barrier(). >> >> >> OK, I see your point. But, ICC has support for GCC inline assembly. So >> the change does not seem to be making any difference. We are using our >> own asm barrier rather than the inbuilt one provided by ICC. > > > It does make a difference: gcc inline assembly is not supported by > /ecc/, see that it's wrapped within the ifdef __ECC part. I believe, > that should be for ia64 which we have under arch/, no? Yes, looks like this breaks building the kernel with ecc compiler on IA64. Has anyone tried building it with ECC on ia64 lately(or ever)? Reviewed-by: Pranith Kumar -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro
On Wed, Apr 29, 2015 at 10:59 AM, mancha security wrote: > > The problem is that ICC defines __GNUC__ so barrier() gets defined > in compiler-gcc.h. Your commit removed an #undef from compiler-intel.h > so compiler.h will never define barrier to __memory_barrier(). > OK, I see your point. But, ICC has support for GCC inline assembly. So the change does not seem to be making any difference. We are using our own asm barrier rather than the inbuilt one provided by ICC. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro
Hi Daniel,
On Wed, Apr 29, 2015 at 10:42 AM, Daniel Borkmann wrote:
> Cleanup commit 23ebdedc67e ("compiler-intel.h: Remove duplicate
> definition") removed the double definition of __memory_barrier()
> intrinsics.
>
> However, in doing so, it also removed the preceding #undef barrier,
> meaning, the actual barrier() macro from compiler-gcc.h with inline
> asm is still in place when __GNUC__ is provided.
When you use the Intel compilers, the barrier() definition will come
from compiler.h and not compiler-gcc.h. That is what the commit
message says in 73679e508201(your commit message has the wrong hash).
I don't understand what problem you are seeing with this, can you
please explain?
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)
On Wed, Apr 22, 2015 at 4:40 PM, Mathieu Desnoyers wrote: > - Original Message - >> On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers >> wrote: >> > diff --git a/init/Kconfig b/init/Kconfig >> > index f5dbc6d..89bad6a 100644 >> > --- a/init/Kconfig >> > +++ b/init/Kconfig >> > @@ -1559,6 +1559,19 @@ config PCI_QUIRKS >> > bugs/quirks. Disable this only if your target machine is >> > unaffected by PCI quirks. >> > >> > +config MEMBARRIER >> > + bool "Enable membarrier() system call" if EXPERT >> > + default y >> > + depends on SMP >> > + help >> > + Enable the membarrier() system call that allows issuing memory >> > + barriers across all running threads, which can be used to >> > distribute >> > + the cost of user-space memory barriers asymmetrically by >> > transforming >> > + pairs of memory barriers into pairs consisting of membarrier() >> > and a >> > + compiler barrier. >> > + >> > + If unsure, say Y. >> > + >> >> I understand why this syscall makes sense on SMP only, but you are >> anyways checking num_online_cpus() and returning if it is only one. Is >> this limitation necessary then? How do !SMP systems handle this >> syscall? (I am guessing glibc wrapper?) > > For !SMP, this system call is not implemented (returns -ENOSYS). > Userspace libs are expected to query sysconf(_SC_NPROCESSORS_CONF) > and check whether the system supports multiprocessor at all. If > only a single processor is supported by the kernel, then userspace > can skip the calls to sys_membarrier altogether, because they are > not even needed. > > Do you think this kind of information belongs in a man page ? > > Should we instead just implement the system call in !SMP, and > return 0 without any side-effect ? This would be a bit inefficient > to let userspace call a system call that has no effect whatsoever. > Are there any other SMP-only system calls like this? I am not really sure what is the right way but documenting it would be good. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)
On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers
wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index f5dbc6d..89bad6a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1559,6 +1559,19 @@ config PCI_QUIRKS
> bugs/quirks. Disable this only if your target machine is
> unaffected by PCI quirks.
>
> +config MEMBARRIER
> + bool "Enable membarrier() system call" if EXPERT
> + default y
> + depends on SMP
> + help
> + Enable the membarrier() system call that allows issuing memory
> + barriers across all running threads, which can be used to distribute
> + the cost of user-space memory barriers asymmetrically by
> transforming
> + pairs of memory barriers into pairs consisting of membarrier() and a
> + compiler barrier.
> +
> + If unsure, say Y.
> +
I understand why this syscall makes sense on SMP only, but you are
anyways checking num_online_cpus() and returning if it is only one. Is
this limitation necessary then? How do !SMP systems handle this
syscall? (I am guessing glibc wrapper?)
...
> +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> +{
> + switch (cmd) {
> + case MEMBARRIER_CMD_QUERY:
> + return MEMBARRIER_CMD_BITMASK;
> + case MEMBARRIER_CMD_SHARED:
> + if (num_online_cpus() > 1)
> + synchronize_sched();
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/12] RCU Kconfig fixes for v4.2
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney wrote: > Hello! > > This patch series reduces the number of questions that RCU asks Kconfig > users. After this series is applied, removing the RCU-related definitions > from .config and running "make oldconfig" results in only the following: > > RCU Implementation >> 1. Tree-based hierarchical RCU (TREE_RCU) (NEW) > choice[1]: 1 > Make expert-level adjustments to RCU configuration (RCU_EXPERT) [N/y/?] (NEW) > > Those expert users wishing to tune RCU answer Y to this question. > > The patches in this series are as follows: > > 1. Drive TASKS_RCU directly from Kconfig, for example, by having > RCU_TORTURE_TESTS select it. > > 2. Remove CONFIG_TASKS_RCU=y from the three TASKS_RCU test > scenarios, since this is set by virtue of having rcutorture > configured. > > 3. Drive RCU_USER_QS directly from Kconfig, relying on the fact > that NO_HZ_FULL selects it. > > 4. Convert CONFIG_RCU_FANOUT_EXACT to a boot parameter, where it > is used by rcutorture. > > 5. Update rcutorture test scenarios to use the boot parameter > created in #4 instead of the Kconfig parameter. > > 6. Create a boot parameter to do a diagnostic dump of the shape > of the rcu_node combining tree, which is useful for verifying > that intended changes to that tree actually happened. > > 7. Create an RCU_EXPERT Kconfig parameter and hide the > RCU_FAST_NO_HZ, RCU_BOOST, CONTEXT_TRACKING_FORCE, and > RCU_NOCB_CPU boolean parameters behind it. > > 8. Make rcutorture test scenarios force RCU_EXPERT, but have > SRCU-P, TASKS03, and TREE09 retain !RCU_EXPERT in order to > test the vanilla configuration. > > 9. Remove the dependency of RCU_FANOUT_LEAF on RCU_FANOUT. > > 10. Change RCU to allow it to tolerate an undefined RCU_FANOUT, > and then hide RCU_FANOUT behind RCU_EXPERT. > > 11. Change RCU to allow it to tolerate an undefined RCU_FANOUT_LEAF, > and then hide RCU_FANOUT_LEAF behind RCU_EXPERT. > > 12. Change RCU to allow it to tolerate an undefined RCU_KTHREAD_PRIO, > and then hide RCU_KTHREAD_PRIO behind RCU_EXPERT. > > Thanx, Paul > With or without the minor changes: Reviewed-by: Pranith Kumar -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 11/12] rcu: Make RCU able to tolerate undefined CONFIG_RCU_FANOUT_LEAF
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
wrote:
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 2e52502bfc95..a2f64e4fdb57 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -86,10 +86,10 @@ static void __init rcu_bootup_announce_oddness(void)
> pr_info("\tAdditional per-CPU info printed with stalls.\n");
> if (RCU_NUM_LVLS >= 4)
> pr_info("\tFour(or more)-level hierarchy is enabled.\n");
> - if (CONFIG_RCU_FANOUT_LEAF != 16)
> + if (RCU_FANOUT_LEAF != 16)
So if CONFIG_RCU_FANOUT_LEAF is either by default 32 or 64, this check
against 16 for build-time adjustment is a bit misleading, no?
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 09/12] rcu: Break dependency of RCU_FANOUT_LEAF on RCU_FANOUT
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > RCU_FANOUT_LEAF's range and default values depend on the value of > RCU_FANOUT, which at the time seemed like a cute way to save two lines > of Kconfig code. However, adding a dependency from both of these > Kconfig parameters on RCU_EXPERT requires that RCU_FANOUT_LEAF operate > correctly even if RCU_FANOUT is undefined. This commit therefore > allows RCU_FANOUT_LEAF to take on the full range of permitted values, > even in cases where RCU_FANOUT is undefined. > > Signed-off-by: Paul E. McKenney > --- > init/Kconfig | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index aa68d72fe051..35559e07db18 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -599,9 +599,11 @@ config RCU_FANOUT > > config RCU_FANOUT_LEAF > int "Tree-based hierarchical RCU leaf-level fanout value" > - range 2 RCU_FANOUT if 64BIT > - range 2 RCU_FANOUT if !64BIT > + range 2 64 if 64BIT > + range 2 32 if !64BIT > depends on TREE_RCU || PREEMPT_RCU > + default 64 if 64BIT > + default 32 if !64BIT > default 16 What is the effect of this 'default 16' line? It is either 64 or 32 based on 64BIT, not sure when it is 16... > help > This option controls the leaf-level fanout of hierarchical > -- > 1.8.1.5 > -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 05/12] rcutorture: Update configuration fragments for rcutree.rcu_fanout_exact
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit updates rcutortures configuration-fragment files to account > for the move from the CONFIG_RCU_FANOUT_EXACT Kconfig parameter to the > new rcutree.rcu_fanout_exact= boot parameter. > > Signed-off-by: Paul E. McKenney There are some some references to it in tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt. I think it will be good to modify them with this commit. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] rcu: config: Remove prompt for RCU implementation
The RCU implementation which is chosen is dependent on PREEMPT and SMP config options and is not really a user-selectable choice. The following change will remove the menu entry and will be derived from the above two options. Signed-off-by: Pranith Kumar --- init/Kconfig | 18 ++ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 0b37750..7707e4a 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -463,13 +463,9 @@ endmenu # "CPU/Task time and stats accounting" menu "RCU Subsystem" -choice - prompt "RCU Implementation" - default TREE_RCU - config TREE_RCU - bool "Tree-based hierarchical RCU" - depends on !PREEMPT && SMP + bool + default y if !PREEMPT && SMP help This option selects the RCU implementation that is designed for very large SMP system with hundreds or @@ -477,8 +473,8 @@ config TREE_RCU smaller systems. config PREEMPT_RCU - bool "Preemptible tree-based hierarchical RCU" - depends on PREEMPT + bool + default y if PREEMPT help This option selects the RCU implementation that is designed for very large SMP systems with hundreds or @@ -489,16 +485,14 @@ config PREEMPT_RCU Select this option if you are unsure. config TINY_RCU - bool "UP-only small-memory-footprint RCU" - depends on !PREEMPT && !SMP + bool + default y if !PREEMPT && !SMP help This option selects the RCU implementation that is designed for UP systems from which real-time response is not required. This option greatly reduces the memory footprint of RCU. -endchoice - config RCU_EXPERT bool "Make expert-level adjustments to RCU configuration" default n -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rcu: small rcu_dereference doc update
On Fri, Apr 17, 2015 at 12:15 PM, Paul E. McKenney wrote: > Sounds like a good thought for a separate patch. Please take a look > through the rest of the documentation -- this might well be the right > place for such an example, but there might well be a better place. > Is this issue mentioned in the checklist? If not, another item might > be good. > Yup, I will take a look and send a patch for this. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rcu: small rcu_dereference doc update
On Fri, Apr 17, 2015 at 6:33 AM, Milos Vyletel wrote:
> Make a note stating that repeated calls of rcu_dereference() may not
> return the same pointer if update happens while in critical section.
Might as well make it more explicit with an example then. See below:
>
> Reported-by: Jeff Haran
> Signed-off-by: Milos Vyletel
> ---
> Documentation/RCU/whatisRCU.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
> index 88dfce1..82b1b2c 100644
> --- a/Documentation/RCU/whatisRCU.txt
> +++ b/Documentation/RCU/whatisRCU.txt
> @@ -256,7 +256,9 @@ rcu_dereference()
> If you are going to be fetching multiple fields from the
> RCU-protected structure, using the local variable is of
> course preferred. Repeated rcu_dereference() calls look
> - ugly and incur unnecessary overhead on Alpha CPUs.
> + ugly, do not guarantee that same pointer will be returned
> + if update happened while in critical section and incur
> + unnecessary overhead on Alpha CPUs.
>
An example like follows:
struct some_ds {
int data;
bool ready;
};
struct some_ds *p = ...;
rcu_read_lock();
if (rcu_dereference(p->ready))
data = rcu_dereference(p->data); // bug
rcu_read_unlock();
or some such.
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] README: Update references to version 4
Since we bumped the version to 4.0, let us update the references to match that in the README file. Signed-off-by: Pranith Kumar --- README | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/README b/README index a24ec89..dbe9c96 100644 --- a/README +++ b/README @@ -1,6 +1,6 @@ -Linux kernel release 3.x <http://kernel.org/> +Linux kernel release 4.x <http://kernel.org/> -These are the release notes for Linux version 3. Read them carefully, +These are the release notes for Linux version 4. Read them carefully, as they tell you what this is all about, explain how to install the kernel, and what to do if something goes wrong. @@ -62,11 +62,11 @@ INSTALLING the kernel source: directory where you have permissions (eg. your home directory) and unpack it: - gzip -cd linux-3.X.tar.gz | tar xvf - + gzip -cd linux-4.X.tar.gz | tar xvf - or - bzip2 -dc linux-3.X.tar.bz2 | tar xvf - + bzip2 -dc linux-4.X.tar.bz2 | tar xvf - Replace "X" with the version number of the latest kernel. @@ -75,16 +75,16 @@ INSTALLING the kernel source: files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be. - - You can also upgrade between 3.x releases by patching. Patches are + - You can also upgrade between 4.x releases by patching. Patches are distributed in the traditional gzip and the newer bzip2 format. To install by patching, get all the newer patch files, enter the - top level directory of the kernel source (linux-3.X) and execute: + top level directory of the kernel source (linux-4.X) and execute: - gzip -cd ../patch-3.x.gz | patch -p1 + gzip -cd ../patch-4.x.gz | patch -p1 or - bzip2 -dc ../patch-3.x.bz2 | patch -p1 + bzip2 -dc ../patch-4.x.bz2 | patch -p1 Replace "x" for all versions bigger than the version "X" of your current source tree, _in_order_, and you should be ok. You may want to remove @@ -92,13 +92,13 @@ INSTALLING the kernel source: that there are no failed patches (some-file-name# or some-file-name.rej). If there are, either you or I have made a mistake. - Unlike patches for the 3.x kernels, patches for the 3.x.y kernels + Unlike patches for the 4.x kernels, patches for the 4.x.y kernels (also known as the -stable kernels) are not incremental but instead apply - directly to the base 3.x kernel. For example, if your base kernel is 3.0 - and you want to apply the 3.0.3 patch, you must not first apply the 3.0.1 - and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2 and - want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that is, - patch -R) _before_ applying the 3.0.3 patch. You can read more on this in + directly to the base 4.x kernel. For example, if your base kernel is 4.0 + and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1 + and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and + want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is, + patch -R) _before_ applying the 4.0.3 patch. You can read more on this in Documentation/applying-patches.txt Alternatively, the script patch-kernel can be used to automate this @@ -120,7 +120,7 @@ INSTALLING the kernel source: SOFTWARE REQUIREMENTS - Compiling and running the 3.x kernels requires up-to-date + Compiling and running the 4.x kernels requires up-to-date versions of various software packages. Consult Documentation/Changes for the minimum version numbers required and how to get updates for these packages. Beware that using @@ -137,12 +137,12 @@ BUILD directory for the kernel: place for the output files (including .config). Example: - kernel source code: /usr/src/linux-3.X + kernel source code: /usr/src/linux-4.X build directory:/home/name/build/kernel To configure and build the kernel, use: - cd /usr/src/linux-3.X + cd /usr/src/linux-4.X make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install @@ -297,7 +297,7 @@ COMPILING the kernel: LOCALVERSION can be set in the "General Setup" menu. - In order to boot your new kernel, you'll need to copy the kernel - image (e.g. .../linux/arch/i386/boot/bzImage after compilation) + image (e.g. .../linux/arch/x86/boot/bzImage after compilation) to the place where your regular bootable kernel is found. - Booting a kernel directly from a floppy without the assistance of a @@ -399,7 +399,7 @@ IF SOMETHING GOES WRONG: - Alternatively, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the - kernel with -g; edit arch/i386/Makefile appropriately, t
[PATCH] nouveau: gt215: Fix clock freq. calculation
In commit 6a4a47cfd181 ("drm/nva3/clk: Set PLL refclk") diff was changed from
int to u32 because of which a later branch which was testing if (diff < 0)
became always false. Fix this by using int type for diff.
Signed-off-by: Pranith Kumar
CC: sta...@vger.kernel.org
CC: Roy Spliet
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
index 822d32a..db37db3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
@@ -180,7 +180,8 @@ gt215_clk_info(struct nvkm_clk *clock, int clk, u32 khz,
struct gt215_clk_info *info)
{
struct gt215_clk_priv *priv = (void *)clock;
- u32 oclk, sclk, sdiv, diff;
+ u32 oclk, sclk, sdiv;
+ int diff;
info->clk = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux panic on 4.0.0-rc4
On Tue, Mar 17, 2015 at 4:13 PM, Peter Hurley wrote: > On 03/17/2015 04:07 PM, Pranith Kumar wrote: >> On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley >> wrote: >>> >>> Can you send me a complete dmesg capture from a boot with >>> this commit reverted? >>> >> >> Here it is. Let me know if you want any boot options enabled. I >> removed both debug and verbose boot options. > > Ok, thanks. > > This is just like Andreas' problem: with my patch, there is _no_ console. > > Note those console command line options in your config aren't actually > in your kernel command line. That really threw me; I couldn't figure out > how you didn't have a tty0 console. > >> [0.00] Kernel command line: >> root=UUID=7252209a-6106-41c2-90a3-45b85ac47837 ro video=radeonfb:off >> video=offb:off radeon.modeset=1 radeon.agpmode=-1 > Hmm, interesting. These arguments are passed from the yaboot.conf which has a line as follows: append="video=radeonfb:off video=offb:off radeon.modeset=1 radeon.agpmode=-1" I thought this would append these arguments to the default kernel command line argument in the config. Apparently it is not. So, the resolution for this is to add the console argument to yaboot.conf I guess, right? -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux panic on 4.0.0-rc4
On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley wrote: > > Can you send me a complete dmesg capture from a boot with > this commit reverted? > Here it is. Let me know if you want any boot options enabled. I removed both debug and verbose boot options. [0.00] Using PowerMac machine description [0.00] Total memory = 1024MB; using 2048kB for hash table (at cfe0) [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.0.0-rc4+ (pranith@macmini) (gcc version 4.9.2 (Debian 4.9.2-10) ) #67 Tue Mar 17 12:40:16 EDT 2015 [0.00] Found initrd at 0xc130:0xc1692000 [0.00] Found UniNorth memory controller & host bridge @ 0xf800 revision: 0xd2 [0.00] Mapped at 0xff7c [0.00] Found a Intrepid mac-io controller, rev: 0, mapped at 0xff74 [0.00] Processor NAP mode on idle enabled. [0.00] PowerMac motherboard: Mac mini (Late 2005) [0.00] bootconsole [udbg0] enabled [0.00] Found UniNorth PCI host bridge at 0xf000. Firmware bus number: 0->0 [0.00] PCI host bridge /pci@f000 ranges: [0.00] MEM 0xf100..0xf1ff -> 0xf100 [0.00] IO 0xf000..0xf07f -> 0x [0.00] MEM 0x9000..0x9fff -> 0x9000 [0.00] Found UniNorth PCI host bridge at 0xf200. Firmware bus number: 0->0 [0.00] PCI host bridge /pci@f200 (primary) ranges: [0.00] MEM 0xf300..0xf3ff -> 0xf300 [0.00] IO 0xf200..0xf27f -> 0x [0.00] MEM 0x8000..0x8fff -> 0x8000 [0.00] Found UniNorth PCI host bridge at 0xf400. Firmware bus number: 0->0 [0.00] PCI host bridge /pci@f400 ranges: [0.00] MEM 0xf500..0xf5ff -> 0xf500 [0.00] IO 0xf400..0xf47f -> 0x [0.00] via-pmu: Server Mode is disabled [0.00] PMU driver v2 initialized for Core99, firmware: 55 [0.00] Top of RAM: 0x4000, Total RAM: 0x4000 [0.00] Memory hole size: 0MB [0.00] Zone ranges: [0.00] DMA [mem 0x-0x2fff] [0.00] Normal empty [0.00] HighMem [mem 0x3000-0x3fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x3fff] [0.00] Initmem setup node 0 [mem 0x-0x3fff] [0.00] On node 0 totalpages: 262144 [0.00] free_area_init_node: node 0, pgdat c05a4a64, node_mem_map ef6e3000 [0.00] DMA zone: 1728 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 196608 pages, LIFO batch:31 [0.00] HighMem zone: 65536 pages, LIFO batch:15 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260416 [0.00] Kernel command line: root=UUID=7252209a-6106-41c2-90a3-45b85ac47837 ro video=radeonfb:off video=offb:off radeon.modeset=1 radeon.agpmode=-1 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 1026292K/1048576K available (3980K kernel code, 212K rwdata, 1384K rodata, 240K init, 294K bss, 22284K reserved, 0K cma-reserved, 262144K highmem) [0.00] Kernel virtual memory layout: [0.00] * 0xfffcf000..0xf000 : fixmap [0.00] * 0xff80..0xffc0 : highmem PTEs [0.00] * 0xfdde4000..0xff80 : early ioremap [0.00] * 0xf100..0xfdde4000 : vmalloc & ioremap [0.00] NR_IRQS:512 nr_irqs:512 16 [0.00] mpic: Resetting [0.00] mpic: Setting up MPIC " MPIC 1 " version 1.2 at 8004, max 1 CPUs [0.00] mpic: ISU size: 64, shift: 6, mask: 3f [0.00] mpic: Initializing for 64 sources [0.00] time_init: decrementer frequency = 41.600571 MHz [0.00] time_init: processor frequency = 1333.28 MHz [0.08] clocksource: timebase mult[1809c2fe] shift[24] registered [0.000394] clockevent: decrementer mult[aa655c4] shift[32] cpu[0] [0.000647] Console: colour dummy device 80x25 [0.000998] console [tty0] enabled [0.001333] bootconsole [udbg0] disabled [0.001859] pid_max: default: 32768 minimum: 301 [0.001902] Mount-cache hash table entries: 2048 (order: 1, 8192 by
Re: linux panic on 4.0.0-rc4
On Mon, Mar 16, 2015 at 11:18 PM, Peter Hurley wrote: > On 03/16/2015 11:12 PM, Pranith Kumar wrote: >> On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley >> wrote: >>>>> What is your init? >>>> >>>> I am using systemd from debian unstable. >>> >>> Do you have a stdout-path property defined in your dts to a serial >>> console you're not actually using? >>> >> >> I am using tty0 as my console. From the config which I posted, it has: >> >> CONFIG_CMDLINE="console=ttyS0,9600 console=tty0" >> >> I am not using any device tree file. > > Ok; there was some reported breakage on PowerMac wrt to 'stdout-path' > changes I made, so I thought I'd check if that might have affected > your setup as well. > And the painful slow bisecting did lead to that commit: Bisecting: 0 revisions left to test after this (roughly 0 steps) [2fa645cb2703d9b3786d850db815414dfeefa51d] of: Fix premature bootconsole disable with 'stdout-path' $ git show 2fa645cb2703d9b3786d850db815414dfeefa51d commit 2fa645cb2703d9b3786d850db815414dfeefa51d Author: Peter Hurley Date: Sun Mar 1 12:21:22 2015 -0500 of: Fix premature bootconsole disable with 'stdout-path' Support for devicetree serial consoles via 'stdout-path' causes bootconsoles to be disabled when the vt dummy console loads, since there is no preferred console (the preferred console is not added until the device is probed). Ensure there is at least a preferred console, even if never matched. More info: $ git bisect log git bisect start # bad: [06e5801b8cb3fc057d88cb4dc03c0b64b2744cda] Linux 4.0-rc4 git bisect bad 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda # good: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19 git bisect good bfa76d49576599a4b9f9b7a71f23d73d6dcff735 # good: [1a67e256dbd80f47f339c4a88c34deee12489aa0] ARM: mvebu: ISL12057 rtc chip can now wake up RN102, RN102 and RN2120 git bisect good 1a67e256dbd80f47f339c4a88c34deee12489aa0 # good: [878ba61aa98cbb97a513757800e77613f856a029] Merge tag 'soc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 878ba61aa98cbb97a513757800e77613f856a029 # good: [18a8d49973667aa016e68826eeb374788b7c63b0] Merge tag 'clk-for-linus-3.20' of git://git.linaro.org/people/mike.turquette/linux git bisect good 18a8d49973667aa016e68826eeb374788b7c63b0 # good: [bfda4031621b048ca634abc5f6bce1aa490ac4e5] MAINTAINERS: Add myself as co-maintainer to the legacy support of the mvebu SoCs git bisect good bfda4031621b048ca634abc5f6bce1aa490ac4e5 # good: [29191c7f71aa55401c83df60482417d3c511edde] Merge tag 'char-misc-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc git bisect good 29191c7f71aa55401c83df60482417d3c511edde # good: [36bef88380037288d5b575ed2029de694533b1ec] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net git bisect good 36bef88380037288d5b575ed2029de694533b1ec # bad: [3d52c5bdbe57e2b45d9cc8da930b9ab42b5198c4] Merge tag 'devicetree-fixes-for-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux git bisect bad 3d52c5bdbe57e2b45d9cc8da930b9ab42b5198c4 # good: [91e9134eda82b57952fdbdb0c5990a7a6609ff13] Merge tag 'pci-v4.0-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci git bisect good 91e9134eda82b57952fdbdb0c5990a7a6609ff13 # good: [c202baf017aea0c860e53131bc55bb1af7177e76] Merge branch 'akpm' (patches from Andrew) git bisect good c202baf017aea0c860e53131bc55bb1af7177e76 # bad: [649022e08e4798ffb6e9b11c56ee6b2c62465d11] of/unittest: Fix the wrong expected value in of_selftest_property_string git bisect bad 649022e08e4798ffb6e9b11c56ee6b2c62465d11 # good: [2c192699a7050ef5bdf1e2cc95fdddfbcf524509] Merge tag 'v4.0-rc3' into HEAD git bisect good 2c192699a7050ef5bdf1e2cc95fdddfbcf524509 # bad: [d3a891652adb82e1973348c703a597cb54e41dea] of/overlay: Remove unused variable git bisect bad d3a891652adb82e1973348c703a597cb54e41dea # bad: [20aa4d8ae8d2ada8f959364ebc096b8841245456] Documentation: DT: Renamed of-serial.txt to 8250.txt git bisect bad 20aa4d8ae8d2ada8f959364ebc096b8841245456 Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux panic on 4.0.0-rc4
On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley wrote: >>> What is your init? >> >> I am using systemd from debian unstable. > > Do you have a stdout-path property defined in your dts to a serial > console you're not actually using? > I am using tty0 as my console. From the config which I posted, it has: CONFIG_CMDLINE="console=ttyS0,9600 console=tty0" I am not using any device tree file. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux panic on 4.0.0-rc4
On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman wrote: > > The log shows that init is being killed, that's what's causing the panic. > > The exitcode of init is 0x200, which due to the vagaries of UNIX is I think an > "exit status" of 2 in the common usage. > > But it suggests that your init is just exiting for some reason? > Yeah, seems like that. Not sure why though. git bisect seems to be the only option. > What is your init? I am using systemd from debian unstable. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux panic on 4.0.0-rc4
On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman wrote: > On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote: >> On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar wrote: >> > Hello, >> > >> > I have a power mac mini 32-bit system. >> > >> ... >> > You can see the panic message here: http://imgur.com/s1lH15g. (there >> > is no log and I have no serial console). >> >> There was some debug code in there when it hit. The actual hang seems >> to be in printk_late_init(). It does not return from this. May be this >> is a hint? > > That is where the boot consoles get disabled and it switches to the "real" > console. It suggests that the system is not "hung" there but you just lost > output. > > Try booting with "keep_bootcon" ? I tried this and got to the same place as in the first mail: http://imgur.com/s1lH15g There is a kernel panic with the message printed. Any more suggestions to how to debug this? -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux panic on 4.0.0-rc4
On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar wrote: > Hello, > > I have a power mac mini 32-bit system. > ... > You can see the panic message here: http://imgur.com/s1lH15g. (there > is no log and I have no serial console). There was some debug code in there when it hit. The actual hang seems to be in printk_late_init(). It does not return from this. May be this is a hint? Please let me know if you need more information to debug this. Thanks! > > Let me know if you need any more information. Config follows: > > # > # Automatically generated file; DO NOT EDIT. > # Linux/powerpc 4.0.0-rc4 Kernel Configuration > # > # CONFIG_PPC64 is not set > > # > # Processor support > # > CONFIG_PPC_BOOK3S_32=y > # CONFIG_PPC_85xx is not set > # CONFIG_PPC_8xx is not set > # CONFIG_40x is not set > # CONFIG_44x is not set > # CONFIG_E200 is not set > CONFIG_PPC_BOOK3S=y > CONFIG_6xx=y > CONFIG_PPC_FPU=y > CONFIG_ALTIVEC=y > CONFIG_PPC_STD_MMU=y > CONFIG_PPC_STD_MMU_32=y > # CONFIG_PPC_MM_SLICES is not set > CONFIG_PPC_HAVE_PMU_SUPPORT=y > CONFIG_PPC_PERF_CTRS=y > # CONFIG_SMP is not set > # CONFIG_PPC_DOORBELL is not set > CONFIG_CPU_BIG_ENDIAN=y > # CONFIG_CPU_LITTLE_ENDIAN is not set > CONFIG_PPC32=y > CONFIG_32BIT=y > CONFIG_WORD_SIZE=32 > # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set > # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set > CONFIG_MMU=y > # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set > # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set > CONFIG_NR_IRQS=512 > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_LATENCYTOP_SUPPORT=y > CONFIG_TRACE_IRQFLAGS_SUPPORT=y > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_ARCH_HAS_ILOG2_U32=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_PPC=y > # CONFIG_GENERIC_CSUM is not set > CONFIG_EARLY_PRINTK=y > CONFIG_PANIC_TIMEOUT=0 > CONFIG_GENERIC_NVRAM=y > CONFIG_SCHED_OMIT_FRAME_POINTER=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_PPC_OF=y > CONFIG_PPC_UDBG_16550=y > # CONFIG_GENERIC_TBSYNC is not set > CONFIG_AUDIT_ARCH=y > CONFIG_GENERIC_BUG=y > # CONFIG_EPAPR_BOOT is not set > # CONFIG_DEFAULT_UIMAGE is not set > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > # CONFIG_PPC_DCR_NATIVE is not set > # CONFIG_PPC_DCR_MMIO is not set > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > CONFIG_ARCH_SUPPORTS_UPROBES=y > CONFIG_PPC_EMULATE_SSTEP=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > CONFIG_IRQ_WORK=y > > # > # General setup > # > CONFIG_BROKEN_ON_SMP=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_CROSS_COMPILE="" > # CONFIG_COMPILE_TEST is not set > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_DEFAULT_HOSTNAME="(none)" > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > CONFIG_POSIX_MQUEUE=y > CONFIG_POSIX_MQUEUE_SYSCTL=y > CONFIG_CROSS_MEMORY_ATTACH=y > CONFIG_FHANDLE=y > CONFIG_USELIB=y > CONFIG_AUDIT=y > CONFIG_HAVE_ARCH_AUDITSYSCALL=y > CONFIG_AUDITSYSCALL=y > CONFIG_AUDIT_WATCH=y > CONFIG_AUDIT_TREE=y > > # > # IRQ subsystem > # > CONFIG_GENERIC_IRQ_SHOW=y > CONFIG_GENERIC_IRQ_SHOW_LEVEL=y > CONFIG_IRQ_DOMAIN=y > CONFIG_GENERIC_MSI_IRQ=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_SPARSE_IRQ=y > CONFIG_GENERIC_TIME_VSYSCALL_OLD=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_GENERIC_CMOS_UPDATE=y > > # > # Timers subsystem > # > CONFIG_TICK_ONESHOT=y > CONFIG_NO_HZ_COMMON=y > # CONFIG_HZ_PERIODIC is not set > CONFIG_NO_HZ_IDLE=y > # CONFIG_NO_HZ is not set > CONFIG_HIGH_RES_TIMERS=y > > # > # CPU/Task time and stats accounting > # > CONFIG_TICK_CPU_ACCOUNTING=y > CONFIG_BSD_PROCESS_ACCT=y > CONFIG_BSD_PROCESS_ACCT_V3=y > CONFIG_TASKSTATS=y > CONFIG_TASK_DELAY_ACCT=y > CONFIG_TASK_XACCT=y > CONFIG_TASK_IO_ACCOUNTING=y > > # > # RCU Subsystem > # > CONFIG_TINY_RCU=y > CONFIG_SRCU=y > CONFIG_TASKS_RCU=y > # CONFIG_RCU_STALL_COMMON is not set > # CONFIG_TREE_RCU_TRACE is not set > CONFIG_RCU_KTHREAD_PRIO=0 > CONFIG_BUILD_BIN2C=y > CONFIG_IKCONFIG=m > # CONFIG_IKCONFIG_PROC is not set > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_CGROUPS=y > # CONFIG_CGROUP_DEBUG is not set > CONFIG_CGROUP_FREEZER=y > CONFIG_CGROUP_DEVICE=y > CONFIG_CPUSETS=y > CONFIG_PROC_PID_CPUSET=y > CONFIG_CGROUP_CPUACCT=y > CONFIG_PAGE_COUNTER=y > CONFIG_MEMCG=y > CONFIG_MEMCG_SWAP=y > # CONFIG_MEMCG_SWAP_ENABLED is not set > CONFIG_CGROUP_PERF=y > CONFIG_CGROUP_SCHED=y > CONFIG_FAIR_GROUP_SCHED=y > # CONFIG_CFS_BANDWIDTH is not set > # CONFIG_RT_GROUP_SCHED is not set &
linux panic on 4.0.0-rc4
Hello, I have a power mac mini 32-bit system. I am getting a kernel panic with the latest rc kernel. The last kernel which worked on this which I remember booting was 3.19-rc5. You can see the panic message here: http://imgur.com/s1lH15g. (there is no log and I have no serial console). Let me know if you need any more information. Config follows: # # Automatically generated file; DO NOT EDIT. # Linux/powerpc 4.0.0-rc4 Kernel Configuration # # CONFIG_PPC64 is not set # # Processor support # CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_PPC_HAVE_PMU_SUPPORT=y CONFIG_PPC_PERF_CTRS=y # CONFIG_SMP is not set # CONFIG_PPC_DOORBELL is not set CONFIG_CPU_BIG_ENDIAN=y # CONFIG_CPU_LITTLE_ENDIAN is not set CONFIG_PPC32=y CONFIG_32BIT=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set CONFIG_MMU=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set CONFIG_NR_IRQS=512 CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_PPC=y # CONFIG_GENERIC_CSUM is not set CONFIG_EARLY_PRINTK=y CONFIG_PANIC_TIMEOUT=0 CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_EPAPR_BOOT is not set # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_PPC_EMULATE_SSTEP=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL_OLD=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y # CONFIG_MEMCG_SWAP_ENABLED is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_BPF_SYSCALL=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y CONFIG_PCI_QUIRKS=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Ke
[PATCH] audit: Remove condition which always evaluates to false
After commit 3e1d0bb6224f019893d1c498cc3327559d183674 ("audit: Convert int limit
uses to u32"), by converting an int to u32, few conditions will always evaluate
to false.
These warnings were emitted during compilation:
kernel/audit.c: In function ‘audit_set_enabled’:
kernel/audit.c:347:2: warning: comparison of unsigned expression < 0 is always
false [-Wtype-limits]
if (state < AUDIT_OFF || state > AUDIT_LOCKED)
^
kernel/audit.c: In function ‘audit_receive_msg’:
kernel/audit.c:880:9: warning: comparison of unsigned expression < 0
is
always false [-Wtype-limits]
if (s.backlog_wait_time < 0 ||
The following patch removes those unnecessary conditions.
Signed-off-by: Pranith Kumar
---
kernel/audit.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 72ab759..b1006cb 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -344,7 +344,7 @@ static int audit_set_backlog_wait_time(u32 timeout)
static int audit_set_enabled(u32 state)
{
int rc;
- if (state < AUDIT_OFF || state > AUDIT_LOCKED)
+ if (state > AUDIT_LOCKED)
return -EINVAL;
rc = audit_do_config_change("audit_enabled", &audit_enabled, state);
@@ -877,8 +877,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct
nlmsghdr *nlh)
if (s.mask & AUDIT_STATUS_BACKLOG_WAIT_TIME) {
if (sizeof(s) > (size_t)nlh->nlmsg_len)
return -EINVAL;
- if (s.backlog_wait_time < 0 ||
- s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
+ if (s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
return -EINVAL;
err = audit_set_backlog_wait_time(s.backlog_wait_time);
if (err < 0)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer
On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas wrote: > > Do you mean the cmpxchg_double() change? Becuase %w0 and %0 is the same > physical register. You set it to 0 and immediately override it with > ldxp. > Thanks Catalin. I realized the blunder a while after Will pointed it out. The asm here was a bit confusing. %0 usually refers to the first input/output variable. But for ldxp instruction(which is just a double-word load, not exclusive), it refers to the physical registers. What about the changes in cmpxchg()? Why do we need to set %w0 to 0 after the ldxrh instruction? Also, could you please point me to any arm64 asm reference? Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer
On Fri, Feb 27, 2015 at 3:17 PM, Pranith Kumar wrote:
> On Fri, Feb 27, 2015 at 3:15 PM, Will Deacon wrote:
>>> @@ -166,11 +166,11 @@ static inline int __cmpxchg_double(volatile void
>>> *ptr1, volatile void *ptr2,
>>> VM_BUG_ON((unsigned long *)ptr2 - (unsigned long *)ptr1 != 1);
>>> do {
>>> asm volatile("// __cmpxchg_double8\n"
>>> + " mov %w0, #0\n"
>>> " ldxp%0, %1, %2\n"
>>
>> Seriously, you might want to test this before you mindlessly make changes to
>> low-level synchronisation code. Not only is the change completely unnecessary
>> but it is actively harmful.
>>
>
> Oops, I apologize for this. I should have looked more closely. It is
> wrong to do this in cmpxchg_double(). What about the other cases?
>
Hi Will,
I tried looking closely on what might be the problem here. I am
waiting on a HiKey arm64 board and I agree I should not send in
changes without running/testing them first.
Could you please explain (for educational purposes) why you think this
change is harmful?
Thanks,
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer
On Fri, Feb 27, 2015 at 3:15 PM, Will Deacon wrote:
> On Fri, Feb 27, 2015 at 08:09:17PM +0000, Pranith Kumar wrote:
>> ARM64 documentation recommends keeping exclusive loads and stores as close as
>> possible. Any instructions which do not depend on the value loaded should be
>> moved outside.
>>
>> In the current implementation of cmpxchg(), there is a mov instruction which
>> can
>> be pulled before the load exclusive instruction without any change in
>> functionality. This patch does that change.
>>
>> Signed-off-by: Pranith Kumar
>> ---
>> arch/arm64/include/asm/cmpxchg.h | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> [...]
>
>> @@ -166,11 +166,11 @@ static inline int __cmpxchg_double(volatile void
>> *ptr1, volatile void *ptr2,
>> VM_BUG_ON((unsigned long *)ptr2 - (unsigned long *)ptr1 != 1);
>> do {
>> asm volatile("// __cmpxchg_double8\n"
>> + " mov %w0, #0\n"
>> " ldxp%0, %1, %2\n"
>
> Seriously, you might want to test this before you mindlessly make changes to
> low-level synchronisation code. Not only is the change completely unnecessary
> but it is actively harmful.
>
Oops, I apologize for this. I should have looked more closely. It is
wrong to do this in cmpxchg_double(). What about the other cases?
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer
ARM64 documentation recommends keeping exclusive loads and stores as close as
possible. Any instructions which do not depend on the value loaded should be
moved outside.
In the current implementation of cmpxchg(), there is a mov instruction which can
be pulled before the load exclusive instruction without any change in
functionality. This patch does that change.
Signed-off-by: Pranith Kumar
---
arch/arm64/include/asm/cmpxchg.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index cb95930..8057735 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -89,8 +89,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
case 1:
do {
asm volatile("// __cmpxchg1\n"
- " ldxrb %w1, %2\n"
" mov %w0, #0\n"
+ " ldxrb %w1, %2\n"
" cmp %w1, %w3\n"
" b.ne1f\n"
" stxrb %w0, %w4, %2\n"
@@ -104,8 +104,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
case 2:
do {
asm volatile("// __cmpxchg2\n"
- " ldxrh %w1, %2\n"
" mov %w0, #0\n"
+ " ldxrh %w1, %2\n"
" cmp %w1, %w3\n"
" b.ne1f\n"
" stxrh %w0, %w4, %2\n"
@@ -119,8 +119,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
case 4:
do {
asm volatile("// __cmpxchg4\n"
- " ldxr%w1, %2\n"
" mov %w0, #0\n"
+ " ldxr%w1, %2\n"
" cmp %w1, %w3\n"
" b.ne1f\n"
" stxr%w0, %w4, %2\n"
@@ -134,8 +134,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
case 8:
do {
asm volatile("// __cmpxchg8\n"
- " ldxr%1, %2\n"
" mov %w0, #0\n"
+ " ldxr%1, %2\n"
" cmp %1, %3\n"
" b.ne1f\n"
" stxr%w0, %4, %2\n"
@@ -166,11 +166,11 @@ static inline int __cmpxchg_double(volatile void *ptr1,
volatile void *ptr2,
VM_BUG_ON((unsigned long *)ptr2 - (unsigned long *)ptr1 != 1);
do {
asm volatile("// __cmpxchg_double8\n"
+ " mov %w0, #0\n"
" ldxp%0, %1, %2\n"
" eor %0, %0, %3\n"
" eor %1, %1, %4\n"
" orr %1, %0, %1\n"
- " mov %w0, #0\n"
" cbnz%1, 1f\n"
" stxp%w0, %5, %6, %2\n"
"1:\n"
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
On Fri, Feb 27, 2015 at 2:08 PM, Mark Rutland wrote: > On Fri, Feb 27, 2015 at 06:44:19PM +0000, Pranith Kumar wrote: >> On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas >> wrote: >> > It's either badly formatted or I don't get it. Are the "stxr x1" and >> > "stxr x7" happening on the same CPU (P0)? If yes, that's badly written >> > code, not even architecturally compliant (you are not allowed other >> > memory accesses between ldxr and stxr). >> >> OK. Is that the same case with ldaxr (acquire) and stlxr (release)? >> AFAIK, memory accesses between acquire and release exclusive >> operations are allowed. > > The restriction on memory accesses in the middle of a load-exclusive > store-exclusive sequence applies to all the load/store-exclusive > variants, including ldaxr and stlxr. > Thanks Mark. I am trying to see where this restriction is documented. Looking at: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802a/a64_data_transfer_alpha.html I do not see that mentioned. The only restriction relevant is that a stxr should use the same address as the most recent ldxr. Could you please point me to the relevant documentation? Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas wrote: > It's either badly formatted or I don't get it. Are the "stxr x1" and > "stxr x7" happening on the same CPU (P0)? If yes, that's badly written > code, not even architecturally compliant (you are not allowed other > memory accesses between ldxr and stxr). OK. Is that the same case with ldaxr (acquire) and stlxr (release)? AFAIK, memory accesses between acquire and release exclusive operations are allowed. > >> The last store exclusive succeeds since the exclusive bit is set which >> should not happen. Clearing the exclusive bit before returning from cmpxchg >> prevents this happening. >> >> Now I am not sure how likely this will happen. One can argue that a cmpxchg() >> will not happen between an external ldxr/stxr. But isn't clearing the >> exclusive >> bit better? > > The only way cmpxchg() could happen between a different ldxr/stxr is > during an interrupt. But ERET automatically clears the exclusive > monitor, so the "stxr x7" would not succeed. That makes sense. But please consider the ldaxr/stlxr case and let me know. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
On Fri, Feb 27, 2015 at 5:06 AM, Will Deacon wrote: > On Fri, Feb 27, 2015 at 05:46:55AM +0000, Pranith Kumar wrote: >> In cmpxchg(), we do a load exclusive on an address and upon a comparison >> fail, >> we skip the store exclusive instruction. This can result in the exclusive bit >> still set. If there was a store exclusive after this to the same address, >> that >> will see the exclusive bit set. This should not happen. > > ... and the problem with that is? Consider the following scenario: P0P1 - ldxr x7, [B] // exclusive bit set add x7, x7, #1 str ..., [B] // exclusive bit cleared cmpxchg: ldxr x0, [B] // exclusive bit set cmp x0, #0// cmp fails b.ne 1f // branch taken stxr x1, [B] // end of cmpxchg 1: stxr x7, [B]// succeeds? The last store exclusive succeeds since the exclusive bit is set which should not happen. Clearing the exclusive bit before returning from cmpxchg prevents this happening. Now I am not sure how likely this will happen. One can argue that a cmpxchg() will not happen between an external ldxr/stxr. But isn't clearing the exclusive bit better? -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
In cmpxchg(), we do a load exclusive on an address and upon a comparison fail, we skip the store exclusive instruction. This can result in the exclusive bit still set. If there was a store exclusive after this to the same address, that will see the exclusive bit set. This should not happen. We need to clear the exclusive bit in these cases. Signed-off-by: Pranith Kumar --- arch/arm64/include/asm/cmpxchg.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h index cb95930..ed2cf90 100644 --- a/arch/arm64/include/asm/cmpxchg.h +++ b/arch/arm64/include/asm/cmpxchg.h @@ -94,7 +94,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, " cmp %w1, %w3\n" " b.ne1f\n" " stxrb %w0, %w4, %2\n" - "1:\n" + "1: clrex\n" : "=&r" (res), "=&r" (oldval), "+Q" (*(u8 *)ptr) : "Ir" (old), "r" (new) : "cc"); @@ -109,7 +109,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, " cmp %w1, %w3\n" " b.ne1f\n" " stxrh %w0, %w4, %2\n" - "1:\n" + "1: clrex\n" : "=&r" (res), "=&r" (oldval), "+Q" (*(u16 *)ptr) : "Ir" (old), "r" (new) : "cc"); @@ -124,7 +124,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, " cmp %w1, %w3\n" " b.ne1f\n" " stxr%w0, %w4, %2\n" - "1:\n" + "1: clrex\n" : "=&r" (res), "=&r" (oldval), "+Q" (*(u32 *)ptr) : "Ir" (old), "r" (new) : "cc"); @@ -139,7 +139,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, " cmp %1, %3\n" " b.ne1f\n" " stxr%w0, %4, %2\n" - "1:\n" + "1: clrex\n" : "=&r" (res), "=&r" (oldval), "+Q" (*(u64 *)ptr) : "Ir" (old), "r" (new) : "cc"); @@ -173,7 +173,7 @@ static inline int __cmpxchg_double(volatile void *ptr1, volatile void *ptr2, " mov %w0, #0\n" " cbnz%1, 1f\n" " stxp%w0, %5, %6, %2\n" - "1:\n" + "1: clrex\n" : "=&r"(loop), "=&r"(lost), "+Q" (*(u64 *)ptr1) : "r" (old1), "r"(old2), "r"(new1), "r"(new2)); } while (loop); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wed, Feb 25, 2015 at 11:21 AM, Arnd Bergmann wrote:
>>
>> More information:
>> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
>> [ 45.833324] [ cut here ]
>> [ 45.837939] kernel BUG at
>> /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
>> [ 45.846450] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>> [ 45.852275] Modules linked in: test(O+) nvhost_vi
>> [ 45.857012] CPU: 0 PID: 1848 Comm: insmod Tainted: G O
>> 3.10.24-g6a2d13a #1
>> [ 45.864744] task: ee406580 ti: eb18c000 task.ti: eb18c000
>> [ 45.870141] PC is at __bad_xchg+0x24/0x28
>> [ 45.874146] LR is at __bad_xchg+0x24/0x28
>
> I'm more interested in the backtrace here, it's possible we should fix the
> driver instead.
I should have been more clearer. I apologize. This is in a test module
I wrote trying out the various synchronization primitives. This is not
a problem in any current driver I am using.
>
>> >> arch/arm/include/asm/cmpxchg.h | 18 +-
>> >> 1 file changed, 17 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm/include/asm/cmpxchg.h
>> >> b/arch/arm/include/asm/cmpxchg.h
>> >> index abb2c37..9505cca 100644
>> >> --- a/arch/arm/include/asm/cmpxchg.h
>> >> +++ b/arch/arm/include/asm/cmpxchg.h
>> >> @@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x,
>> >> volatile void *ptr, int size
>> >> : "r" (x), "r" (ptr)
>> >> : "memory", "cc");
>> >> break;
>> >> + case 2:
>> >> + asm volatile("@ __xchg2\n"
>> >> + "1: ldrexh %0, [%3]\n"
>> >> + " strexh %1, %2, [%3]\n"
>> >> + " teq %1, #0\n"
>> >> + " bne 1b"
>> >> + : "=&r" (ret), "=&r" (tmp)
>> >> + : "r" (x), "r" (ptr)
>> >> + : "memory", "cc");
>> >> + break;
>> >> case 4:
>> >> asm volatile("@ __xchg4\n"
>> >> "1: ldrex %0, [%3]\n"
>> >
>> > Does this work on all ARMv6 or just ARMv6k?
>> >
>>
>> ldrexh/strexh is being used in cmpxchg() in the same file in a similar
>> manner, and the comment there says that it works for all ARCH >=
>> ARMv6k, so not ARMv6 I guess.
>
> Ok, then you need to put the same check in __xchg too. I'm not sure
> about the 1-byte case here, because that is already used in ARMv6
> __xchg.
>
OK, I will update the patch with the check.
Looking closely I see what you are saying. In __xchg(), for the 1 byte
case we are using ldrexb/strexb while the test checks for version >=
6. Documentation online says that ldrex{h/b} are supported only for
ARMv6k or greater.
So I think the check in __xchg() should be changed to one similar in
cmpxchg(). Is that what you meant?
If so, i will send in an updated patch.
Thanks!
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wed, Feb 25, 2015 at 12:14 PM, Russell King - ARM Linux wrote: > Actually, I think we ought to get rid of __bad_xchg() so that cases > like this cause a link error instead of a runtime error, just like we > do in other cases as well. > > That's something that goes back ages (it used to be called something > like invalidptr in 2.0 kernels...) That sounds like a good idea. I will cook up a patch doing this. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wed, Feb 25, 2015 at 12:02 PM, Russell King - ARM Linux wrote: >> Unfortunately, the BUG message seems incomplete, can you reproduce this >> with CONFIG_DEBUG_BUGVERBOSE enabled? > > That isn't because CONFIG_DEBUG_BUGVERBOSE isn't set. It's because > the message author decided that the remainder of the kernel bug message > wasn't useful to report. After all, it's just a load of hex numbers > and symbolic information. Who would want that junk. > > (Some people really don't get this: we print stuff from the kernel > because it gives _us_ useful information to debug problems like this, > but because they don't understand it themselves, they decide they can > omit it from their bug reports...) > I apologize for not pasting the entire back trace. It was in a test module I wrote testing synchronization primitives and did not think the back trace would be useful to report. I will include verbose details from now on. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm: asm/cmpxchg.h: Add support half-word xchg()
On Wed, Feb 25, 2015 at 10:58 AM, Arnd Bergmann wrote:
> On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote:
>> This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
>> instructions. It also fixes an asm comment for __cmpxchg2.
>>
>> Currently using a half-word xchg() results in the following splat on an ARMv7
>> machine.
>>
>> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
>> [ 45.833324] [ cut here ]
>> [ 45.837939] kernel BUG at
>> /dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
>>
>> Signed-off-by: Pranith Kumar
>
> Unfortunately, the BUG message seems incomplete, can you reproduce this
> with CONFIG_DEBUG_BUGVERBOSE enabled?
The bug here is in a module caused when xchg() was used on uint16_t
variable. It is caused by the __bad_xchg() for 2 byte swap.
More information:
[ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
/dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
[ 45.846450] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 45.852275] Modules linked in: test(O+) nvhost_vi
[ 45.857012] CPU: 0 PID: 1848 Comm: insmod Tainted: G O
3.10.24-g6a2d13a #1
[ 45.864744] task: ee406580 ti: eb18c000 task.ti: eb18c000
[ 45.870141] PC is at __bad_xchg+0x24/0x28
[ 45.874146] LR is at __bad_xchg+0x24/0x28
>
>> arch/arm/include/asm/cmpxchg.h | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
>> index abb2c37..9505cca 100644
>> --- a/arch/arm/include/asm/cmpxchg.h
>> +++ b/arch/arm/include/asm/cmpxchg.h
>> @@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x,
>> volatile void *ptr, int size
>> : "r" (x), "r" (ptr)
>> : "memory", "cc");
>> break;
>> + case 2:
>> + asm volatile("@ __xchg2\n"
>> + "1: ldrexh %0, [%3]\n"
>> + " strexh %1, %2, [%3]\n"
>> + " teq %1, #0\n"
>> + " bne 1b"
>> + : "=&r" (ret), "=&r" (tmp)
>> + : "r" (x), "r" (ptr)
>> + : "memory", "cc");
>> + break;
>> case 4:
>> asm volatile("@ __xchg4\n"
>> "1: ldrex %0, [%3]\n"
>
> Does this work on all ARMv6 or just ARMv6k?
>
ldrexh/strexh is being used in cmpxchg() in the same file in a similar
manner, and the comment there says that it works for all ARCH >=
ARMv6k, so not ARMv6 I guess.
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] arm: asm/cmpxchg.h: Add support half-word xchg()
This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
instructions. It also fixes an asm comment for __cmpxchg2.
Currently using a half-word xchg() results in the following splat on an ARMv7
machine.
[ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
/dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
Signed-off-by: Pranith Kumar
---
arch/arm/include/asm/cmpxchg.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index abb2c37..9505cca 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -50,6 +50,16 @@ static inline unsigned long __xchg(unsigned long x, volatile
void *ptr, int size
: "r" (x), "r" (ptr)
: "memory", "cc");
break;
+ case 2:
+ asm volatile("@ __xchg2\n"
+ "1: ldrexh %0, [%3]\n"
+ " strexh %1, %2, [%3]\n"
+ " teq %1, #0\n"
+ " bne 1b"
+ : "=&r" (ret), "=&r" (tmp)
+ : "r" (x), "r" (ptr)
+ : "memory", "cc");
+ break;
case 4:
asm volatile("@ __xchg4\n"
"1: ldrex %0, [%3]\n"
@@ -93,6 +103,12 @@ static inline unsigned long __xchg(unsigned long x,
volatile void *ptr, int size
: "memory", "cc");
break;
#endif
+ case 2:
+ raw_local_irq_save(flags);
+ ret = *(volatile uint16_t *)ptr;
+ *(volatile uint16_t *)ptr = x;
+ raw_local_irq_restore(flags);
+ break;
default:
__bad_xchg(ptr, size), ret = 0;
break;
@@ -158,7 +174,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
break;
case 2:
do {
- asm volatile("@ __cmpxchg1\n"
+ asm volatile("@ __cmpxchg2\n"
" ldrexh %1, [%2]\n"
" mov %0, #0\n"
" teq %1, %3\n"
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] llist: Fix missing memory barrier
Hi Mathieu, On Thu, Feb 5, 2015 at 10:06 PM, Mathieu Desnoyers wrote: > A smp_read_barrier_depends() appears to be missing in llist_del_first(). > It should only matter for Alpha in practice. Adding it after the check > of entry against NULL allows skipping the barrier in a common case. We recently decided on using lockless_dereference() instead of hard-coding smp_read_barrier_depends()[1]. The advantage is that lockless_dereference() clearly shows what loads are being ordered. Could you resend the patch using that API? Thanks! [1] http://lkml.iu.edu/hypermail/linux/kernel/1410.3/04561.html > > Signed-off-by: Mathieu Desnoyers > CC: Huang Ying > CC: Paul McKenney > CC: David Howells > --- > lib/llist.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/llist.c b/lib/llist.c > index f76196d..72861f3 100644 > --- a/lib/llist.c > +++ b/lib/llist.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > > /** > @@ -72,6 +73,12 @@ struct llist_node *llist_del_first(struct llist_head *head) > if (entry == NULL) > return NULL; > old_entry = entry; > + /* > +* Load entry before entry->next. Matches the implicit > +* memory barrier before the cmpxchg in llist_add_batch(), > +* which ensures entry->next is stored before entry. > +*/ > + smp_read_barrier_depends(); > next = entry->next; > entry = cmpxchg(&head->first, old_entry, next); > if (entry == old_entry) > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n
On Thu, Jan 22, 2015 at 5:35 PM, Stewart Smith wrote: > Pranith Kumar writes: >> On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman >> wrote: >>> On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote: >>>> When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get() >>>> return 0. Check for these return values and skip registering the dump >>>> buffer. >>>> >>>> Signed-off-by: Pranith Kumar >>>> CC: Michael Ellerman >>>> --- >>>> arch/powerpc/platforms/powernv/opal.c | 6 ++ >>>> 1 file changed, 6 insertions(+) >>> >>> What changed since v1? I don't see anything? >>> >> >> Nothing in this patch but there is a v2 of the first patch in this >> series, so had to resend this patch with a v2. > > You also missed my Reviewed-by :) > Sincere apologies for the oversight. Maintainers, could you please add this Reviewed-by tag when picking this up? Reviewed-by: Stewart Smith Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n
On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman wrote: > On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote: >> When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get() >> return 0. Check for these return values and skip registering the dump buffer. >> >> Signed-off-by: Pranith Kumar >> CC: Michael Ellerman >> --- >> arch/powerpc/platforms/powernv/opal.c | 6 ++ >> 1 file changed, 6 insertions(+) > > What changed since v1? I don't see anything? > Nothing in this patch but there is a v2 of the first patch in this series, so had to resend this patch with a v2. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get() return 0. Check for these return values and skip registering the dump buffer. Signed-off-by: Pranith Kumar CC: Michael Ellerman --- arch/powerpc/platforms/powernv/opal.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c index f10b9ec..1db119f0 100644 --- a/arch/powerpc/platforms/powernv/opal.c +++ b/arch/powerpc/platforms/powernv/opal.c @@ -667,7 +667,13 @@ static void __init opal_dump_region_init(void) /* Register kernel log buffer */ addr = log_buf_addr_get(); + if (addr == NULL) + return; + size = log_buf_len_get(); + if (size == 0) + return; + rc = opal_register_dump_region(OPAL_DUMP_REGION_LOG_BUF, __pa(addr), size); /* Don't warn if this is just an older OPAL that doesn't -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] printk: Add dummy routine for when CONFIG_PRINTK=n
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar
CC: Michael Ellerman
---
include/linux/printk.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index aeb9d7f..baa3f97 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -10,9 +10,6 @@
extern const char linux_banner[];
extern const char linux_proc_banner[];
-extern char *log_buf_addr_get(void);
-extern u32 log_buf_len_get(void);
-
static inline int printk_get_level(const char *buffer)
{
if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
@@ -163,6 +160,8 @@ extern int kptr_restrict;
extern void wake_up_klogd(void);
+char *log_buf_addr_get(void);
+u32 log_buf_len_get(void);
void log_buf_kexec_setup(void);
void __init setup_log_buf(int early);
void dump_stack_set_arch_desc(const char *fmt, ...);
@@ -198,6 +197,16 @@ static inline void wake_up_klogd(void)
{
}
+static inline char *log_buf_addr_get(void)
+{
+ return NULL;
+}
+
+static inline u32 log_buf_len_get(void)
+{
+ return 0;
+}
+
static inline void log_buf_kexec_setup(void)
{
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] printk: Add dummy routine for when CONFIG_PRINTK=n
On Wed, Jan 21, 2015 at 7:58 AM, Petr Mladek wrote:
> On Tue 2015-01-20 18:51:49, Pranith Kumar wrote:
>> There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
>> for when CONFIG_PRINTK is not set causing build failures.
>>
>> This patch adds these dummy routines at the appropriate location.
>>
>> Signed-off-by: Pranith Kumar
>> CC: Michael Ellerman
>> ---
>> include/linux/printk.h | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/printk.h b/include/linux/printk.h
>> index aeb9d7f..f52f02b 100644
>> --- a/include/linux/printk.h
>> +++ b/include/linux/printk.h
>> @@ -10,9 +10,6 @@
>> extern const char linux_banner[];
>> extern const char linux_proc_banner[];
>>
>> -extern char *log_buf_addr_get(void);
>> -extern u32 log_buf_len_get(void);
>> -
>> static inline int printk_get_level(const char *buffer)
>> {
>> if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
>> @@ -168,6 +165,8 @@ void __init setup_log_buf(int early);
>> void dump_stack_set_arch_desc(const char *fmt, ...);
>> void dump_stack_print_info(const char *log_lvl);
>> void show_regs_print_info(const char *log_lvl);
>> +char *log_buf_addr_get(void);
>> +u32 log_buf_len_get(void);
>> #else
>> static inline __printf(1, 0)
>> int vprintk(const char *s, va_list args)
>> @@ -217,6 +216,16 @@ static inline void dump_stack_print_info(const char
>> *log_lvl)
>> static inline void show_regs_print_info(const char *log_lvl)
>> {
>> }
>> +
>> +static inline char *log_buf_addr_get(void)
>> +{
>> + return NULL;
>> +}
>> +
>> +static linline u32 log_buf_len_get(void)
> ^
> typo: linline -> inline
Argh, shows why we should always atleast build test before sending a
patch, no matter how trivial it is.
>
> Otherwise, it looks fine to me.
>
> Well, If you send v2, I would move this above log_buf_kexec_setup() in
> both #ifdef branches. So that all four log_buf()-related functions
> declared/defined together.
I will update as you said in v2.
Thanks!
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get() return 0. Check for these return values and skip registering the dump buffer. Signed-off-by: Pranith Kumar CC: Michael Ellerman --- arch/powerpc/platforms/powernv/opal.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c index f10b9ec..1db119f0 100644 --- a/arch/powerpc/platforms/powernv/opal.c +++ b/arch/powerpc/platforms/powernv/opal.c @@ -667,7 +667,13 @@ static void __init opal_dump_region_init(void) /* Register kernel log buffer */ addr = log_buf_addr_get(); + if (addr == NULL) + return; + size = log_buf_len_get(); + if (size == 0) + return; + rc = opal_register_dump_region(OPAL_DUMP_REGION_LOG_BUF, __pa(addr), size); /* Don't warn if this is just an older OPAL that doesn't -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] printk: Add dummy routine for when CONFIG_PRINTK=n
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar
CC: Michael Ellerman
---
include/linux/printk.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index aeb9d7f..f52f02b 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -10,9 +10,6 @@
extern const char linux_banner[];
extern const char linux_proc_banner[];
-extern char *log_buf_addr_get(void);
-extern u32 log_buf_len_get(void);
-
static inline int printk_get_level(const char *buffer)
{
if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
@@ -168,6 +165,8 @@ void __init setup_log_buf(int early);
void dump_stack_set_arch_desc(const char *fmt, ...);
void dump_stack_print_info(const char *log_lvl);
void show_regs_print_info(const char *log_lvl);
+char *log_buf_addr_get(void);
+u32 log_buf_len_get(void);
#else
static inline __printf(1, 0)
int vprintk(const char *s, va_list args)
@@ -217,6 +216,16 @@ static inline void dump_stack_print_info(const char
*log_lvl)
static inline void show_regs_print_info(const char *log_lvl)
{
}
+
+static inline char *log_buf_addr_get(void)
+{
+ return NULL;
+}
+
+static linline u32 log_buf_len_get(void)
+{
+ return 0;
+}
#endif
extern asmlinkage void dump_stack(void) __cold;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
On Mon, Dec 29, 2014 at 4:01 AM, Michael Ellerman 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] assoc_array: Include rcupdate.h for call_rcu() definition
Include rcupdate.h header to provide call_rcu() definition. This was implicitly being provided by slab.h file which include srcu.h somewhere in its include hierarchy which in-turn included rcupdate.h. Lately, tinification effort added support to remove srcu entirely because of which we are encountering build errors like lib/assoc_array.c: In function 'assoc_array_apply_edit': lib/assoc_array.c:1426:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Fix these by including rcupdate.h explicitly. Signed-off-by: Pranith Kumar Reported-by: Scott Wood --- lib/assoc_array.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/assoc_array.c b/lib/assoc_array.c index 2404d03..03dd576 100644 --- a/lib/assoc_array.c +++ b/lib/assoc_array.c @@ -11,6 +11,7 @@ * 2 of the Licence, or (at your option) any later version. */ //#define DEBUG +#include #include #include #include -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU
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
CC: Scott Wood
---
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
#include
#include
-#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#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
#include
#include
-#include
#include
#include
#include
@@ -54,6 +53,10 @@
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#endif
+
#ifdef DEBUG
#include
#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
-#include
#include
#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#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;
+
typedefint (*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)
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Mon, Dec 29, 2014 at 6:05 PM, Scott Wood 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky wrote: > On Sat, 27 Dec 2014 12:17:43 -0500 > Pranith Kumar wrote: > >> @@ -65,10 +65,13 @@ >> #include >> #include >> #include >> -#include >> #include >> #include >> >> +#if IS_ENABLED(CONFIG_KVM) >> +#include >> +#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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the rcu tree
On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar wrote: > On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote: >> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the >> "select SRCU" to "config PPC" in arch/powerpc/Kconfig. Are you able >> to cross-build powerpc? >> > > ppc 32 seems fine without selecting srcu unconditionally. So I added > this select to PPC 64 which should fix this build failure. > On looking at this further, I was able to figure out the parts on ppc64 utilizing KVM and enabled them dependent on CONFIG_KVM being enabled. I tested this with a ppc64 allnoconfig and it built succesfully (depending on a unrelated patch to enable printk for powernv). I've sent the patch but it still seems that we will be playing whack-a-mole for now with code which uses KVM indepedent of CONFIG_KVM. May be fixing it incrementally is a better option than lumping all these together? -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
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
---
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
#include
#include
-#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#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
-#include
#include
#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#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;
+
typedefint (*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,
[PATCH] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the rcu tree
On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote: > Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the > "select SRCU" to "config PPC" in arch/powerpc/Kconfig. Are you able > to cross-build powerpc? > ppc 32 seems fine without selecting srcu unconditionally. So I added this select to PPC 64 which should fix this build failure. I will send the updated patch once I've done some basic tests. Sorry for the delay! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] powerpc: Wire up sys_execveat() syscall
Wire up sys_execveat(). This passes the selftests for the system call. Check success of execveat(3, '../execveat', 0)... [OK] Check success of execveat(5, 'execveat', 0)... [OK] Check success of execveat(6, 'execveat', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...ftests/exec/execveat', 0)... [OK] Check success of execveat(99, '/home/pranith/linux/...ftests/exec/execveat', 0)... [OK] Check success of execveat(8, '', 4096)... [OK] Check success of execveat(17, '', 4096)... [OK] Check success of execveat(9, '', 4096)... [OK] Check success of execveat(14, '', 4096)... [OK] Check success of execveat(14, '', 4096)... [OK] Check success of execveat(15, '', 4096)... [OK] Check failure of execveat(8, '', 0) with ENOENT... [OK] Check failure of execveat(8, '(null)', 4096) with EFAULT... [OK] Check success of execveat(5, 'execveat.symlink', 0)... [OK] Check success of execveat(6, 'execveat.symlink', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...xec/execveat.symlink', 0)... [OK] Check success of execveat(10, '', 4096)... [OK] Check success of execveat(10, '', 4352)... [OK] Check failure of execveat(5, 'execveat.symlink', 256) with ELOOP... [OK] Check failure of execveat(6, 'execveat.symlink', 256) with ELOOP... [OK] Check failure of execveat(-100, '/home/pranith/linux/tools/testing/selftests/exec/execveat.symlink', 256) with ELOOP... [OK] Check success of execveat(3, '../script', 0)... [OK] Check success of execveat(5, 'script', 0)... [OK] Check success of execveat(6, 'script', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...elftests/exec/script', 0)... [OK] Check success of execveat(13, '', 4096)... [OK] Check success of execveat(13, '', 4352)... [OK] Check failure of execveat(18, '', 4096) with ENOENT... [OK] Check failure of execveat(7, 'script', 0) with ENOENT... [OK] Check success of execveat(16, '', 4096)... [OK] Check success of execveat(16, '', 4096)... [OK] Check success of execveat(4, '../script', 0)... [OK] Check success of execveat(4, 'script', 0)... [OK] Check success of execveat(4, '../script', 0)... [OK] Check failure of execveat(4, 'script', 0) with ENOENT... [OK] Check failure of execveat(5, 'execveat', 65535) with EINVAL... [OK] Check failure of execveat(5, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(6, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(-100, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(5, '', 4096) with EACCES... [OK] Check failure of execveat(5, 'Makefile', 0) with EACCES... [OK] Check failure of execveat(11, '', 4096) with EACCES... [OK] Check failure of execveat(12, '', 4096) with EACCES... [OK] Check failure of execveat(99, '', 4096) with EBADF... [OK] Check failure of execveat(99, 'execveat', 0) with EBADF... [OK] Check failure of execveat(8, 'execveat', 0) with ENOTDIR... [OK] Invoke copy of 'execveat' via filename of length 4093: Check success of execveat(19, '', 4096)... [OK] Check success of execveat(5, '...', 0)... [OK] Invoke copy of 'script' via filename of length 4093: Check success of execveat(20, '', 4096)... [OK] /bin/sh: 0: Can't open /dev/fd/5/xxx(... a long line of x's and y's, 0)... [OK] Check success of execveat(5, '...', 0)... [OK] Tested on a 32-bit powerpc system. Signed-off-by: Pranith Kumar --- arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h index ce9577d..91062ee 100644 --- a/arch/powerpc/include/asm/systbl.h +++ b/arch/powerpc/include/asm/systbl.h @@ -366,3 +366,4 @@ SYSCALL_SPU(seccomp) SYSCALL_SPU(getrandom) SYSCALL_SPU(memfd_create) SYSCALL_SPU(bpf) +COMPAT_SYS(execveat) diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h index e0da021..36b79c3 100644 --- a/arch/powerpc/include/asm/unistd.h +++ b/arch/powerpc/include/asm/unistd.h @@ -12,7 +12,7 @@ #include -#define __NR_syscalls 362 +#define __NR_syscalls 363 #define __NR__exit __NR_exit #define NR_syscalls__NR_syscalls diff --git a/arch/powerpc/include/uapi/asm/unistd.h b/arch/powerpc/include/uapi/asm/unistd.h index f55351f..ef5b5b1 100644 --- a/arch/powerpc/include/uapi/asm/unistd.h +++ b/arch/powerpc/include/uapi/asm/unistd.h @@ -384,5 +384,6 @@ #define __NR_getrandom 359 #define __NR_memfd_create 360 #define __NR_bpf 361 +#define __NR_execveat 362 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Wire up sys_execveat() syscall
On Sun, Dec 21, 2014 at 4:56 AM, Stephen Rothwell wrote: > Hi Pranith, > > On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar > wrote: >> >> Wire up sys_execveat(). This passes the selftests for the system call. > > Thanks for this, but ... > >> diff --git a/arch/powerpc/include/asm/systbl.h >> b/arch/powerpc/include/asm/systbl.h >> index ce9577d..778844a 100644 >> --- a/arch/powerpc/include/asm/systbl.h >> +++ b/arch/powerpc/include/asm/systbl.h >> @@ -366,3 +366,4 @@ SYSCALL_SPU(seccomp) >> SYSCALL_SPU(getrandom) >> SYSCALL_SPU(memfd_create) >> SYSCALL_SPU(bpf) >> +SYSCALL_SPU(execveat) > > Given that it passes pointers into the kernel and looking at the execve > system call, I assume that it should be COMPAT_SYS(). > Yes, you are right. I will send in an updated patch. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Wire up sys_execveat() syscall
Wire up sys_execveat(). This passes the selftests for the system call. Check success of execveat(3, '../execveat', 0)... [OK] Check success of execveat(5, 'execveat', 0)... [OK] Check success of execveat(6, 'execveat', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...ftests/exec/execveat', 0)... [OK] Check success of execveat(99, '/home/pranith/linux/...ftests/exec/execveat', 0)... [OK] Check success of execveat(8, '', 4096)... [OK] Check success of execveat(17, '', 4096)... [OK] Check success of execveat(9, '', 4096)... [OK] Check success of execveat(14, '', 4096)... [OK] Check success of execveat(14, '', 4096)... [OK] Check success of execveat(15, '', 4096)... [OK] Check failure of execveat(8, '', 0) with ENOENT... [OK] Check failure of execveat(8, '(null)', 4096) with EFAULT... [OK] Check success of execveat(5, 'execveat.symlink', 0)... [OK] Check success of execveat(6, 'execveat.symlink', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...xec/execveat.symlink', 0)... [OK] Check success of execveat(10, '', 4096)... [OK] Check success of execveat(10, '', 4352)... [OK] Check failure of execveat(5, 'execveat.symlink', 256) with ELOOP... [OK] Check failure of execveat(6, 'execveat.symlink', 256) with ELOOP... [OK] Check failure of execveat(-100, '/home/pranith/linux/tools/testing/selftests/exec/execveat.symlink', 256) with ELOOP... [OK] Check success of execveat(3, '../script', 0)... [OK] Check success of execveat(5, 'script', 0)... [OK] Check success of execveat(6, 'script', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...elftests/exec/script', 0)... [OK] Check success of execveat(13, '', 4096)... [OK] Check success of execveat(13, '', 4352)... [OK] Check failure of execveat(18, '', 4096) with ENOENT... [OK] Check failure of execveat(7, 'script', 0) with ENOENT... [OK] Check success of execveat(16, '', 4096)... [OK] Check success of execveat(16, '', 4096)... [OK] Check success of execveat(4, '../script', 0)... [OK] Check success of execveat(4, 'script', 0)... [OK] Check success of execveat(4, '../script', 0)... [OK] Check failure of execveat(4, 'script', 0) with ENOENT... [OK] Check failure of execveat(5, 'execveat', 65535) with EINVAL... [OK] Check failure of execveat(5, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(6, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(-100, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(5, '', 4096) with EACCES... [OK] Check failure of execveat(5, 'Makefile', 0) with EACCES... [OK] Check failure of execveat(11, '', 4096) with EACCES... [OK] Check failure of execveat(12, '', 4096) with EACCES... [OK] Check failure of execveat(99, '', 4096) with EBADF... [OK] Check failure of execveat(99, 'execveat', 0) with EBADF... [OK] Check failure of execveat(8, 'execveat', 0) with ENOTDIR... [OK] Invoke copy of 'execveat' via filename of length 4093: Check success of execveat(19, '', 4096)... [OK] Check success of execveat(5, '...', 0)... [OK] Invoke copy of 'script' via filename of length 4093: Check success of execveat(20, '', 4096)... [OK] /bin/sh: 0: Can't open /dev/fd/5/xxx(... a long line of x's and y's, 0)... [OK] Check success of execveat(5, '...', 0)... [OK] Tested on a 32-bit powerpc system. Signed-off-by: Pranith Kumar --- arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h index ce9577d..778844a 100644 --- a/arch/powerpc/include/asm/systbl.h +++ b/arch/powerpc/include/asm/systbl.h @@ -366,3 +366,4 @@ SYSCALL_SPU(seccomp) SYSCALL_SPU(getrandom) SYSCALL_SPU(memfd_create) SYSCALL_SPU(bpf) +SYSCALL_SPU(execveat) diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h index e0da021..36b79c3 100644 --- a/arch/powerpc/include/asm/unistd.h +++ b/arch/powerpc/include/asm/unistd.h @@ -12,7 +12,7 @@ #include -#define __NR_syscalls 362 +#define __NR_syscalls 363 #define __NR__exit __NR_exit #define NR_syscalls__NR_syscalls diff --git a/arch/powerpc/include/uapi/asm/unistd.h b/arch/powerpc/include/uapi/asm/unistd.h index f55351f..ef5b5b1 100644 --- a/arch/powerpc/include/uapi/asm/unistd.h +++ b/arch/powerpc/include/uapi/asm/unistd.h @@ -384,5 +384,6 @@ #define __NR_getrandom 359 #define __NR_memfd_create 360 #define __NR_bpf 361 +#define __NR_execveat 362 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */ -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the rcu tree
On 12/10/2014 03:09 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
> from arch/powerpc/kernel/setup_64.c:68:
> include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
> struct srcu_struct srcu;
> ^
> include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
> struct srcu_struct irq_srcu;
> ^
>
> Presumably caused by commit 6e8ef258b669 ("srcu: Isolate srcu sections
> using CONFIG_SRCU").
>
> I have reverted that commit again for today - more work required ...
>
Looks like there are other places which use KVM unconditionally. I will try to
look and fix such uses.
Paul, can you drop the patch until then? Thanks!
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] smpboot: Check for successfull allocation of cpumask vars
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and warn on failure
of an allocation in such cases. Also remove the cpus from cpu masks so
that they are not accessed later on.
Signed-off-by: Pranith Kumar
---
arch/x86/kernel/smpboot.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 7a8f584..35bc3f1 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1083,6 +1083,7 @@ static void __init smp_cpu_index_default(void)
void __init native_smp_prepare_cpus(unsigned int max_cpus)
{
unsigned int i;
+ bool ret = true;
preempt_disable();
smp_cpu_index_default();
@@ -1096,9 +1097,23 @@ void __init native_smp_prepare_cpus(unsigned int
max_cpus)
current_thread_info()->cpu = 0; /* needed? */
for_each_possible_cpu(i) {
- zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL);
- zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL);
- zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i), GFP_KERNEL);
+ ret &= zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i),
GFP_KERNEL);
+ ret &= zalloc_cpumask_var(&per_cpu(cpu_core_map, i),
GFP_KERNEL);
+ ret &= zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i),
GFP_KERNEL);
+
+ if (!ret) {
+ /* cpumask allocation failed, remove this and next cpus
from
+* possible/present/online/active masks
+*/
+ pr_warn("cpumask allocation failed!\n");
+ for (; i < nr_cpu_ids; i = cpumask_next(i,
&cpu_possible_mask)) {
+ set_cpu_possible(i, false);
+ set_cpu_active(i, false);
+ set_cpu_online(i, false);
+ set_cpu_present(i, false);
+ }
+ break;
+ }
}
set_cpu_sibling_map(0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] smpboot: Check for successfull allocation of cpumask vars
On Tue, Dec 9, 2014 at 3:10 PM, Thomas Gleixner wrote: > On Tue, 9 Dec 2014, Pranith Kumar wrote: >> zalloc_cpumask_var() can return 0 on allocation failure when >> CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on >> failure >> of an allocation in such cases. > > And that warning helps in which way? > > It just prints a completely useless backtrace and breaks out of the > loop, but it does not prevent that later on code will trip over the > non allocated per cpu data. > I agree. May be just a pr_warn() saying that an allocation failed perhaps? To prevent further accesses, we can clear the cpu bit from the cpu masks(online/possible/present) for the failed cpu and continue trying to allocate for other cpus. We don't break out of the loop. Removing the cpu from the cpu masks will disable accesses of the non allocated per cpu data. What do you suggest we do in such cases? -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
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.
Also make including kvm_host.h conditional on CONFIG_KVM being enabled. This
prevents build failures as KVM is dependent on SRCU.
Signed-off-by: Pranith Kumar
CC: Paul E. McKenney
CC: Josh Triplett
CC: Lai Jiangshan
Signed-off-by: Paul E. McKenney
---
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47 --
include/linux/srcu.h | 6 +-
3 files changed, 38 insertions(+), 22 deletions(-)
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
-#include
#include
#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#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;
+
typedefint (*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_DONE0x /* Don't care */
#define NOTIFY_OK 0x000
[RFC PATCH] smpboot: Check for successfull allocation of cpumask vars
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on failure
of an allocation in such cases.
Signed-off-by: Pranith Kumar
---
arch/x86/kernel/smpboot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 7a8f584..9b1df21 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1083,6 +1083,7 @@ static void __init smp_cpu_index_default(void)
void __init native_smp_prepare_cpus(unsigned int max_cpus)
{
unsigned int i;
+ bool ret = true;
preempt_disable();
smp_cpu_index_default();
@@ -1096,9 +1097,12 @@ void __init native_smp_prepare_cpus(unsigned int
max_cpus)
current_thread_info()->cpu = 0; /* needed? */
for_each_possible_cpu(i) {
- zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL);
- zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL);
- zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i), GFP_KERNEL);
+ ret &= zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i),
GFP_KERNEL);
+ ret &= zalloc_cpumask_var(&per_cpu(cpu_core_map, i),
GFP_KERNEL);
+ ret &= zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i),
GFP_KERNEL);
+
+ if (WARN(!ret, "cpumask alloc for cpu %d failed!", i))
+ break;
}
set_cpu_sibling_map(0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
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.
Also make including kvm_host.h conditional on CONFIG_KVM being enabled. This
prevents build failures as KVM is dependent on SRCU.
Signed-off-by: Pranith Kumar
Acked-by: Christian Borntraeger [for s390 parts]
CC: Josh Triplett
CC: Lai Jiangshan
CC: Paul E. McKenney
---
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47 --
include/linux/srcu.h | 6 +-
3 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..055334d 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -7,12 +7,15 @@
#define ASM_OFFSETS_C
#include
-#include
#include
#include
#include
#include
+#ifdef CONFIG_KVM
+#include
+#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));
+#ifdef 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;
+
typedefint (*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_DONE0x /* Don't care */
#define NOTIFY_OK 0x000
Re: [PATCH] s390: Include kvm_host.h header only if KVM is enabled
On Mon, Dec 8, 2014 at 6:59 PM, Paul E. McKenney wrote: > On Mon, Dec 08, 2014 at 03:24:35PM -0500, Pranith Kumar wrote: >> KVM uses srcu structures because of which CONFIG_KVM selects CONFIG_SRCU. In >> asm-offsets.c, we are including kvm_host.h unconditionally even though >> CONFIG_KVM is not enabled because of which we get errors like follows: >> >> In file included from arch/s390/kernel/asm-offsets.c:10:0: >> >> include/linux/kvm_host.h:363:21: error: field 'srcu' has incomplete type >> struct srcu_struct srcu; >> ^ >> >> include/linux/kvm_host.h:364:21: error: field 'irq_srcu' has incomplete >> >> type >> struct srcu_struct irq_srcu; >> ^ >> make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1 >> make[2]: Target '__build' not remade because of errors. >> make[1]: *** [prepare0] Error 2 >> make[1]: Target 'prepare' not remade because of errors. >> make: *** [sub-make] Error 2 >> >> This patch fixes these by including kvm_host.h conditionally on CONFIG_KVM. >> >> Signed-off-by: Pranith Kumar > > To make the commits bisectable, we need to combine these two patches, > correct? > Yes, if the s390 maintainers raise no objections, I will combine this with the other patch and send it. Thanks! >> --- >> arch/s390/kernel/asm-offsets.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c >> index ef279a1..055334d 100644 >> --- a/arch/s390/kernel/asm-offsets.c >> +++ b/arch/s390/kernel/asm-offsets.c >> @@ -7,12 +7,15 @@ >> #define ASM_OFFSETS_C >> >> #include >> -#include >> #include >> #include >> #include >> #include >> >> +#ifdef CONFIG_KVM >> +#include >> +#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)); >> +#ifdef 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; >> } >> -- >> 1.9.1 >> > -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] s390: Include kvm_host.h header only if KVM is enabled
KVM uses srcu structures because of which CONFIG_KVM selects CONFIG_SRCU. In asm-offsets.c, we are including kvm_host.h unconditionally even though CONFIG_KVM is not enabled because of which we get errors like follows: In file included from arch/s390/kernel/asm-offsets.c:10:0: >> include/linux/kvm_host.h:363:21: error: field 'srcu' has incomplete type struct srcu_struct srcu; ^ >> include/linux/kvm_host.h:364:21: error: field 'irq_srcu' has incomplete type struct srcu_struct irq_srcu; ^ make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [prepare0] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 This patch fixes these by including kvm_host.h conditionally on CONFIG_KVM. Signed-off-by: Pranith Kumar --- arch/s390/kernel/asm-offsets.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c index ef279a1..055334d 100644 --- a/arch/s390/kernel/asm-offsets.c +++ b/arch/s390/kernel/asm-offsets.c @@ -7,12 +7,15 @@ #define ASM_OFFSETS_C #include -#include #include #include #include #include +#ifdef CONFIG_KVM +#include +#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)); +#ifdef 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; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
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.
Signed-off-by: Pranith Kumar
CC: Paul E. McKenney
CC: Josh Triplett
CC: Lai Jiangshan
---
include/linux/notifier.h | 47 +++
include/linux/srcu.h | 6 +-
2 files changed, 32 insertions(+), 21 deletions(-)
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;
+
typedefint (*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_DONE0x /* 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
[PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
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.
Signed-off-by: Pranith Kumar
CC: Paul E. McKenney
CC: Josh Triplett
CC: Lai Jiangshan
---
include/linux/notifier.h | 45 +
include/linux/srcu.h | 6 +-
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d14a4c3..291ecb1 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -70,12 +70,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 +82,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 +90,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 +109,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 +120,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 +133,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_DONE0x /* Don't care */
#define NOTIFY_OK 0x0001 /* Suits me */
@@ -211,5 +191,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
#
Re: [PATCH] tinification: Make SRCU optional by using CONFIG_SRCU
On Thu, Dec 4, 2014 at 9:05 PM, Lai Jiangshan wrote: > On 12/05/2014 08:11 AM, Paul E. McKenney wrote: >> On Thu, Dec 04, 2014 at 06:50:24PM -0500, Pranith Kumar wrote: >>> SRCU is not necessary to be compiled by default in all cases. For >>> tinification >>> efforts not compiling SRCU unless necessary is desirable. >>> >>> The current patch tries to make compiling SRCU optional by introducing a new >>> Kconfig option CONFIG_SRCU which is selected when any of the components >>> making >>> use of SRCU are selected. >>> >>> If we do not select CONFIG_SRCU, srcu.o will not be compiled at all. >>> >>>textdata bss dec hex filename >>>2007 0 02007 7d7 kernel/rcu/srcu.o >>> >>> Size of arch/powerpc/boot/zImage changes from >>> >>>textdata bss dec hex filename >>> 831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before >>> 829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after >>> >>> so the savings are about ~2000 bytes. >>> >>> Signed-off-by: Pranith Kumar >>> CC: Paul McKenney >>> CC: Josh Triplett >> >> I have queued this for testing. >> >> Josh, does this look reasonable to you? >> >> Lai, any issues? >> >> Thanx, Paul >> >>> --- >>> arch/arm/kvm/Kconfig | 1 + >>> arch/arm64/kvm/Kconfig | 1 + >>> arch/ia64/kvm/Kconfig| 1 + >>> arch/mips/kvm/Kconfig| 1 + >>> arch/powerpc/kvm/Kconfig | 1 + >>> arch/s390/kvm/Kconfig| 1 + >>> arch/tile/kvm/Kconfig| 1 + >>> arch/x86/Kconfig | 1 + >>> arch/x86/kvm/Kconfig | 1 + >>> drivers/clk/Kconfig | 1 + >>> drivers/cpufreq/Kconfig | 1 + >>> drivers/devfreq/Kconfig | 1 + >>> drivers/md/Kconfig | 1 + >>> drivers/net/Kconfig | 1 + >>> fs/btrfs/Kconfig | 1 + >>> fs/notify/Kconfig| 1 + >>> init/Kconfig | 10 ++ >>> kernel/notifier.c| 3 +++ >>> kernel/rcu/Makefile | 3 ++- >>> lib/Kconfig.debug| 1 + >>> mm/Kconfig | 1 + >>> security/tomoyo/Kconfig | 1 + >>> 22 files changed, 34 insertions(+), 1 deletion(-) > > Miss fs/quota/Kconfig? > > ./fs/quota/dquot.c:100: * Operation of reading pointer needs > srcu_read_lock(&dquot_srcu), and > ./fs/quota/dquot.c:1609:index = srcu_read_lock(&dquot_srcu); > ./fs/quota/dquot.c:1657:index = srcu_read_lock(&dquot_srcu); > ./fs/quota/dquot.c:1695:index = srcu_read_lock(&dquot_srcu); > ./fs/quota/dquot.c:1724:index = srcu_read_lock(&dquot_srcu); > ./fs/quota/dquot.c:1756:index = srcu_read_lock(&dquot_srcu); > ./fs/quota/dquot.c:1797:index = srcu_read_lock(&dquot_srcu); > ./fs/quota/dquot.c:1827: * protect them by srcu_read_lock(). > > And > > ./drivers/base/power/opp.c:90: struct srcu_notifier_head head; > ./drivers/base/power/opp.c:439: > srcu_init_notifier_head(&dev_opp->head); > ./drivers/base/power/opp.c:484: srcu_notifier_call_chain(&dev_opp->head, > OPP_EVENT_ADD, new_opp); > ./drivers/base/power/opp.c:564: > srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_ENABLE, > ./drivers/base/power/opp.c:567: > srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_DISABLE, > ./drivers/base/power/opp.c:625:struct srcu_notifier_head > *dev_pm_opp_get_notifier(struct device *dev) > > === I've added the above two locations to enable SRCU. > > include/linux/srcu.h and ./include/linux/notifier.h should also use > "#ifdef CONFIG_SRCU " > > >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index ded8a67..1c581a0 100644 >>> --- a/arch/x86/Kconfig >>> +++ b/arch/x86/Kconfig >>> @@ -137,6 +137,7 @@ config X86 >>> select HAVE_ACPI_APEI_NMI if ACPI >>> select ACPI_LEGACY_TABLES_LOOKUP if ACPI >>> select X86_FEATURE_NAMES if PROC_FS >>> +select SRCU > > > > > Why you select SRCU when X86? > The reason is that x86 selects PERF_EVENTS which inturn needs SRCU. We were not sure if SRCU will be recursively enabled when PERF_EVENTS is enabled. >>> >>> +config SRCU >>> +bool "Sleepable form of RCU" > > Why it has a title? Somebody need t
[PATCH] tinification: Make SRCU optional by using CONFIG_SRCU
SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. If we do not select CONFIG_SRCU, srcu.o will not be compiled at all. textdata bss dec hex filename 2007 0 02007 7d7 kernel/rcu/srcu.o Size of arch/powerpc/boot/zImage changes from textdata bss dec hex filename 831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before 829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after so the savings are about ~2000 bytes. Signed-off-by: Pranith Kumar CC: Paul McKenney CC: Josh Triplett --- arch/arm/kvm/Kconfig | 1 + arch/arm64/kvm/Kconfig | 1 + arch/ia64/kvm/Kconfig| 1 + arch/mips/kvm/Kconfig| 1 + arch/powerpc/kvm/Kconfig | 1 + arch/s390/kvm/Kconfig| 1 + arch/tile/kvm/Kconfig| 1 + arch/x86/Kconfig | 1 + arch/x86/kvm/Kconfig | 1 + drivers/clk/Kconfig | 1 + drivers/cpufreq/Kconfig | 1 + drivers/devfreq/Kconfig | 1 + drivers/md/Kconfig | 1 + drivers/net/Kconfig | 1 + fs/btrfs/Kconfig | 1 + fs/notify/Kconfig| 1 + init/Kconfig | 10 ++ kernel/notifier.c| 3 +++ kernel/rcu/Makefile | 3 ++- lib/Kconfig.debug| 1 + mm/Kconfig | 1 + security/tomoyo/Kconfig | 1 + 22 files changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 466bd29..3afee5f 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -23,6 +23,7 @@ config KVM select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_MMIO select KVM_ARM_HOST + select SRCU depends on ARM_VIRT_EXT && ARM_LPAE ---help--- Support hosting virtualized guest machines. You will also diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 8ba85e9..b334084 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -26,6 +26,7 @@ config KVM select KVM_ARM_HOST select KVM_ARM_VGIC select KVM_ARM_TIMER + select SRCU ---help--- Support hosting virtualized guest machines. diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index 3d50ea9..f7d380b 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -29,6 +29,7 @@ config KVM select HAVE_KVM_IRQ_ROUTING select KVM_APIC_ARCHITECTURE select KVM_MMIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig index 30e334e..2ae1282 100644 --- a/arch/mips/kvm/Kconfig +++ b/arch/mips/kvm/Kconfig @@ -20,6 +20,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select KVM_MMIO + select SRCU ---help--- Support for hosting Guest kernels. Currently supported on MIPS32 processors. diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 602eb51..af18e0f 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select HAVE_KVM_EVENTFD + select SRCU config KVM_BOOK3S_HANDLER bool diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index 646db9c..5fce52c 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -28,6 +28,7 @@ config KVM select HAVE_KVM_IRQCHIP select HAVE_KVM_IRQFD select HAVE_KVM_IRQ_ROUTING + select SRCU ---help--- Support hosting paravirtualized guest machines using the SIE virtualization capability on the mainframe. This should work diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig index 2298cb1..1e968f7 100644 --- a/arch/tile/kvm/Kconfig +++ b/arch/tile/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM depends on HAVE_KVM && MODULES select PREEMPT_NOTIFIERS select ANON_INODES + select SRCU ---help--- Support hosting paravirtualized guest machines. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ded8a67..1c581a0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -137,6 +137,7 @@ config X86 select HAVE_ACPI_APEI_NMI if ACPI select ACPI_LEGACY_TABLES_LOOKUP if ACPI select X86_FEATURE_NAMES if PROC_FS + select SRCU config INSTRUCTION_DECODER def_bool y diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index f9d16ff..7dc7ba5 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -40,6 +40,7 @@ config KVM sel
Re: [RFC PATCH v2] tinification: Introduce CONFIG_SRCU to make SRCU optional
(resending, forgot CC's) On Thu, Dec 4, 2014 at 11:13 AM, Josh Triplett wrote: >> >> The current tinyconfig on x86 enables SRCU by default since x86 enables >> PERF_EVENTS which in-turn require SRCU support. If we disable >> PERF_EVENTS, we can disable compiling SRCU for tiny configs on x86 systems. > > To the best of my knowledge, "select" still doesn't recursively enable > things that the selected symbol selects, so I think you need to "select > SRCU" from X86, right next to the "select PERF_EVENTS". Doesn't this prevent not selecting SRCU on x86 systems? I think a warning will be generated during make if a dependent config is not enabled. > > Also, can you try your patch on top of the current patch series to > compile without perf (tiny/disable-perf), and see if you can > successfully compile without SRCU on x86? This branch had a small config error which was compiling perf related code unconditionally. warning: (HW_BREAKPOINTS) selects HAVE_HW_BREAKPOINT which has unmet direct dependencies (PERF_EVENTS) With the following patch applied on top of it I was able to compile my patch. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 10c51ff..0ecc069 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -588,6 +588,7 @@ config HW_BREAKPOINTS default y select HAVE_HW_BREAKPOINT select HAVE_MIXED_BREAKPOINTS_REGS + depends on PERF_EVENTS ---help--- Enable support for x86 hardware breakpoints for debuggers and perf. This will implicitly enable perf-events. > >> I tested this using randconfig and building about 15 kernels. This is >> definitely >> not complete and could use more testing. Sticking it in next might help in >> that >> regards. >> >> Comments and suggestions are welcome. Please let me know if I should split up >> this patch. > > I don't think this needs splitting; it's a very small and obvious patch > combined with a few selects. > > The code looks good to me. Assuming it compiles on x86, with tinyconfig > and with allyesconfig minus SRCU (and whatever requires it), this seems For allyesconfig minus SRCU(using tiny/disable-perf) I needed the following patch to get it to build diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 10c51ff..0ecc069 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -588,6 +588,7 @@ config HW_BREAKPOINTS default y select HAVE_HW_BREAKPOINT select HAVE_MIXED_BREAKPOINTS_REGS + depends on PERF_EVENTS ---help--- Enable support for x86 hardware breakpoints for debuggers and perf. This will implicitly enable perf-events. diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt index 370b24c..2669ddf 100644 --- a/fs/Kconfig.binfmt +++ b/fs/Kconfig.binfmt @@ -182,6 +182,7 @@ config BINFMT_MISC config COREDUMP bool "Enable core dump support" if EXPERT default y + depends on PERF_EVENTS help This option enables support for performing core dumps. You almost certainly want to say Y here. Not necessary on systems that never diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 8639819..b008c597 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -125,6 +125,7 @@ config TRACING_SUPPORT # irqflags tracing for your architecture. depends on TRACE_IRQFLAGS_SUPPORT || PPC32 depends on STACKTRACE_SUPPORT + depends on PERF_EVENTS default y if TRACING_SUPPORT -- If the above two patches are good, then may be you should add them to the tiny/disable-perf branch? I will submit SRCU patch on top of rcu/dev so that Paul can pick it up in his tree. Thanks! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2] tinification: Introduce CONFIG_SRCU to make SRCU optional
On 12/04/2014 01:27 AM, Paul E. McKenney wrote: > For the moment, I applied this to -rcu against v3.18-rc6 to get some 0day > testing on it. > > There are conflicts against the tip of my tree, but will worry about > that later. I don't have a ready answer on whether or not this needs > to be split up -- in the worst case, we would add the SRCU Kconfig > parameter, add all the selects, then once they all hit mainline add the > Makefile change. > > We will need stats on how much memory was saved, and a "size > kernel/rcu/srcu.o" > after a UP/tiny build should do it. Could you please add this to the > commit log? > So if we do not select CONFIG_SRCU, srcu.o will not be compiled at all. So we should save about textdata bss dec hex filename 2007 0 02007 7d7 kernel/rcu/srcu.o as in size of arch/powerpc/boot/zImage changes from textdata bss dec hex filename 831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before 829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after so about ~2000 bytes I guess. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2] tinification: Introduce CONFIG_SRCU to make SRCU optional
(CC list trimmed since this is just for initial feedback) SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. The current tinyconfig on x86 enables SRCU by default since x86 enables PERF_EVENTS which in-turn require SRCU support. If we disable PERF_EVENTS, we can disable compiling SRCU for tiny configs on x86 systems. I tested this using randconfig and building about 15 kernels. This is definitely not complete and could use more testing. Sticking it in next might help in that regards. Comments and suggestions are welcome. Please let me know if I should split up this patch. Signed-off-by: Pranith Kumar CC: Paul McKenney CC: Josh Triplett --- v2: - handle cpufreq, devfreq and notifier - build tested tinyconfig on powerpc arch/arm/kvm/Kconfig | 1 + arch/arm64/kvm/Kconfig | 1 + arch/ia64/kvm/Kconfig| 1 + arch/mips/kvm/Kconfig| 1 + arch/powerpc/kvm/Kconfig | 1 + arch/s390/kvm/Kconfig| 1 + arch/tile/kvm/Kconfig| 1 + arch/x86/kvm/Kconfig | 1 + drivers/clk/Kconfig | 1 + drivers/cpufreq/Kconfig | 1 + drivers/devfreq/Kconfig | 1 + drivers/md/Kconfig | 1 + drivers/net/Kconfig | 1 + fs/btrfs/Kconfig | 1 + fs/notify/Kconfig| 1 + init/Kconfig | 10 ++ kernel/notifier.c| 3 +++ kernel/rcu/Makefile | 3 ++- lib/Kconfig.debug| 1 + mm/Kconfig | 1 + security/tomoyo/Kconfig | 1 + 21 files changed, 33 insertions(+), 1 deletion(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 466bd29..3afee5f 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -23,6 +23,7 @@ config KVM select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_MMIO select KVM_ARM_HOST + select SRCU depends on ARM_VIRT_EXT && ARM_LPAE ---help--- Support hosting virtualized guest machines. You will also diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 8ba85e9..b334084 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -26,6 +26,7 @@ config KVM select KVM_ARM_HOST select KVM_ARM_VGIC select KVM_ARM_TIMER + select SRCU ---help--- Support hosting virtualized guest machines. diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index 3d50ea9..f7d380b 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -29,6 +29,7 @@ config KVM select HAVE_KVM_IRQ_ROUTING select KVM_APIC_ARCHITECTURE select KVM_MMIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig index 30e334e..2ae1282 100644 --- a/arch/mips/kvm/Kconfig +++ b/arch/mips/kvm/Kconfig @@ -20,6 +20,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select KVM_MMIO + select SRCU ---help--- Support for hosting Guest kernels. Currently supported on MIPS32 processors. diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 602eb51..af18e0f 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select HAVE_KVM_EVENTFD + select SRCU config KVM_BOOK3S_HANDLER bool diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index 646db9c..5fce52c 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -28,6 +28,7 @@ config KVM select HAVE_KVM_IRQCHIP select HAVE_KVM_IRQFD select HAVE_KVM_IRQ_ROUTING + select SRCU ---help--- Support hosting paravirtualized guest machines using the SIE virtualization capability on the mainframe. This should work diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig index 2298cb1..1e968f7 100644 --- a/arch/tile/kvm/Kconfig +++ b/arch/tile/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM depends on HAVE_KVM && MODULES select PREEMPT_NOTIFIERS select ANON_INODES + select SRCU ---help--- Support hosting paravirtualized guest machines. diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index f9d16ff..7dc7ba5 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -40,6 +40,7 @@ config KVM select HAVE_KVM_MSI select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_VFIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need
Re: [RFC PATCH] tinification: Introduce CONFIG_SRCU to make SRCU optional
On Wed, Dec 3, 2014 at 8:54 PM, Pranith Kumar wrote: > (CC list restricted since this is just for initial feedback) > > SRCU is not necessary to be compiled by default in all cases. For tinification > efforts not compiling SRCU unless necessary is desirable. > > The current patch tries to make compiling SRCU optional by introducing a new > Kconfig option CONFIG_SRCU which is selected when any of the components making > use of SRCU are selected. > > The current tinyconfig on x86 enables SRCU by default since x86 enables > PERF_EVENTS which in-turn require SRCU support. If we disable PERF_EVENTS, we > can disable compiling SRCU for tiny configs on x86 systems. > > I tested this using randconfig and building about 15 kernels. This is > definitely > not complete and could use more testing. Sticking it in next might help in > that > regards. > > Comments and suggestions are welcome. Please let me know if I should split > up this patch. > > Signed-off-by: Pranith Kumar So it looks like I missed a few places where this needs to be set(cpufreq, devfreq, notifier etc.,) I will update the patch and send it in. Thanks! > CC: Paul McKenney > CC: Josh Triplett > --- > arch/arm/kvm/Kconfig | 1 + > arch/arm64/kvm/Kconfig | 1 + > arch/ia64/kvm/Kconfig| 1 + > arch/mips/kvm/Kconfig| 1 + > arch/powerpc/kvm/Kconfig | 1 + > arch/s390/kvm/Kconfig| 1 + > arch/tile/kvm/Kconfig| 1 + > arch/x86/kvm/Kconfig | 1 + > drivers/md/Kconfig | 1 + > drivers/net/Kconfig | 1 + > fs/btrfs/Kconfig | 1 + > fs/notify/Kconfig| 1 + > init/Kconfig | 10 ++ > kernel/rcu/Makefile | 3 ++- > lib/Kconfig.debug| 1 + > mm/Kconfig | 1 + > security/tomoyo/Kconfig | 1 + > 17 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig > index 466bd29..3afee5f 100644 > --- a/arch/arm/kvm/Kconfig > +++ b/arch/arm/kvm/Kconfig > @@ -23,6 +23,7 @@ config KVM > select HAVE_KVM_CPU_RELAX_INTERCEPT > select KVM_MMIO > select KVM_ARM_HOST > + select SRCU > depends on ARM_VIRT_EXT && ARM_LPAE > ---help--- > Support hosting virtualized guest machines. You will also > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig > index 8ba85e9..b334084 100644 > --- a/arch/arm64/kvm/Kconfig > +++ b/arch/arm64/kvm/Kconfig > @@ -26,6 +26,7 @@ config KVM > select KVM_ARM_HOST > select KVM_ARM_VGIC > select KVM_ARM_TIMER > + select SRCU > ---help--- > Support hosting virtualized guest machines. > > diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig > index 3d50ea9..f7d380b 100644 > --- a/arch/ia64/kvm/Kconfig > +++ b/arch/ia64/kvm/Kconfig > @@ -29,6 +29,7 @@ config KVM > select HAVE_KVM_IRQ_ROUTING > select KVM_APIC_ARCHITECTURE > select KVM_MMIO > + select SRCU > ---help--- > Support hosting fully virtualized guest machines using hardware > virtualization extensions. You will need a fairly recent > diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig > index 30e334e..2ae1282 100644 > --- a/arch/mips/kvm/Kconfig > +++ b/arch/mips/kvm/Kconfig > @@ -20,6 +20,7 @@ config KVM > select PREEMPT_NOTIFIERS > select ANON_INODES > select KVM_MMIO > + select SRCU > ---help--- > Support for hosting Guest kernels. > Currently supported on MIPS32 processors. > diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig > index 602eb51..af18e0f 100644 > --- a/arch/powerpc/kvm/Kconfig > +++ b/arch/powerpc/kvm/Kconfig > @@ -21,6 +21,7 @@ config KVM > select PREEMPT_NOTIFIERS > select ANON_INODES > select HAVE_KVM_EVENTFD > + select SRCU > > config KVM_BOOK3S_HANDLER > bool > diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig > index 646db9c..5fce52c 100644 > --- a/arch/s390/kvm/Kconfig > +++ b/arch/s390/kvm/Kconfig > @@ -28,6 +28,7 @@ config KVM > select HAVE_KVM_IRQCHIP > select HAVE_KVM_IRQFD > select HAVE_KVM_IRQ_ROUTING > + select SRCU > ---help--- > Support hosting paravirtualized guest machines using the SIE > virtualization capability on the mainframe. This should work > diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig > index 2298cb1..1e968f7 100644 > --- a/arch/tile/kvm/Kconfig > +++ b/arch/tile/kvm/Kconfig > @@ -21,6 +21,7 @@ config KVM > depends on HAVE_KVM
[RFC PATCH] tinification: Introduce CONFIG_SRCU to make SRCU optional
(CC list restricted since this is just for initial feedback) SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. The current tinyconfig on x86 enables SRCU by default since x86 enables PERF_EVENTS which in-turn require SRCU support. If we disable PERF_EVENTS, we can disable compiling SRCU for tiny configs on x86 systems. I tested this using randconfig and building about 15 kernels. This is definitely not complete and could use more testing. Sticking it in next might help in that regards. Comments and suggestions are welcome. Please let me know if I should split up this patch. Signed-off-by: Pranith Kumar CC: Paul McKenney CC: Josh Triplett --- arch/arm/kvm/Kconfig | 1 + arch/arm64/kvm/Kconfig | 1 + arch/ia64/kvm/Kconfig| 1 + arch/mips/kvm/Kconfig| 1 + arch/powerpc/kvm/Kconfig | 1 + arch/s390/kvm/Kconfig| 1 + arch/tile/kvm/Kconfig| 1 + arch/x86/kvm/Kconfig | 1 + drivers/md/Kconfig | 1 + drivers/net/Kconfig | 1 + fs/btrfs/Kconfig | 1 + fs/notify/Kconfig| 1 + init/Kconfig | 10 ++ kernel/rcu/Makefile | 3 ++- lib/Kconfig.debug| 1 + mm/Kconfig | 1 + security/tomoyo/Kconfig | 1 + 17 files changed, 27 insertions(+), 1 deletion(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 466bd29..3afee5f 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -23,6 +23,7 @@ config KVM select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_MMIO select KVM_ARM_HOST + select SRCU depends on ARM_VIRT_EXT && ARM_LPAE ---help--- Support hosting virtualized guest machines. You will also diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 8ba85e9..b334084 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -26,6 +26,7 @@ config KVM select KVM_ARM_HOST select KVM_ARM_VGIC select KVM_ARM_TIMER + select SRCU ---help--- Support hosting virtualized guest machines. diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index 3d50ea9..f7d380b 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -29,6 +29,7 @@ config KVM select HAVE_KVM_IRQ_ROUTING select KVM_APIC_ARCHITECTURE select KVM_MMIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig index 30e334e..2ae1282 100644 --- a/arch/mips/kvm/Kconfig +++ b/arch/mips/kvm/Kconfig @@ -20,6 +20,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select KVM_MMIO + select SRCU ---help--- Support for hosting Guest kernels. Currently supported on MIPS32 processors. diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 602eb51..af18e0f 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select HAVE_KVM_EVENTFD + select SRCU config KVM_BOOK3S_HANDLER bool diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index 646db9c..5fce52c 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -28,6 +28,7 @@ config KVM select HAVE_KVM_IRQCHIP select HAVE_KVM_IRQFD select HAVE_KVM_IRQ_ROUTING + select SRCU ---help--- Support hosting paravirtualized guest machines using the SIE virtualization capability on the mainframe. This should work diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig index 2298cb1..1e968f7 100644 --- a/arch/tile/kvm/Kconfig +++ b/arch/tile/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM depends on HAVE_KVM && MODULES select PREEMPT_NOTIFIERS select ANON_INODES + select SRCU ---help--- Support hosting paravirtualized guest machines. diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index f9d16ff..7dc7ba5 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -40,6 +40,7 @@ config KVM select HAVE_KVM_MSI select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_VFIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 5bdedf6..c355a22 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -5,6 +5,7 @@ menuconfig MD bool "Multiple d
[RFC PATCH] tinification: Introduce CONFIG_SRCU to make SRCU optional
(CC list restricted since this is just for initial feedback) SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. The current tinyconfig on x86 enables SRCU by default since x86 enables PERF_EVENTS which in-turn require SRCU support. If we disable PERF_EVENTS, we can disable compiling SRCU for tiny configs on x86 systems. I tested this using randconfig and building about 15 kernels. This is definitely not complete and could use more testing. Sticking it in next might help in that regards. Comments and suggestions are welcome. Please let me know if I should split up this patch. Signed-off-by: Pranith Kumar CC: Paul McKenney CC: Josh Triplett --- arch/arm/kvm/Kconfig | 1 + arch/arm64/kvm/Kconfig | 1 + arch/ia64/kvm/Kconfig| 1 + arch/mips/kvm/Kconfig| 1 + arch/powerpc/kvm/Kconfig | 1 + arch/s390/kvm/Kconfig| 1 + arch/tile/kvm/Kconfig| 1 + arch/x86/kvm/Kconfig | 1 + drivers/md/Kconfig | 1 + drivers/net/Kconfig | 1 + fs/btrfs/Kconfig | 1 + fs/notify/Kconfig| 1 + init/Kconfig | 10 ++ kernel/rcu/Makefile | 3 ++- lib/Kconfig.debug| 1 + mm/Kconfig | 1 + security/tomoyo/Kconfig | 1 + 17 files changed, 27 insertions(+), 1 deletion(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 466bd29..3afee5f 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -23,6 +23,7 @@ config KVM select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_MMIO select KVM_ARM_HOST + select SRCU depends on ARM_VIRT_EXT && ARM_LPAE ---help--- Support hosting virtualized guest machines. You will also diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 8ba85e9..b334084 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -26,6 +26,7 @@ config KVM select KVM_ARM_HOST select KVM_ARM_VGIC select KVM_ARM_TIMER + select SRCU ---help--- Support hosting virtualized guest machines. diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index 3d50ea9..f7d380b 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -29,6 +29,7 @@ config KVM select HAVE_KVM_IRQ_ROUTING select KVM_APIC_ARCHITECTURE select KVM_MMIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig index 30e334e..2ae1282 100644 --- a/arch/mips/kvm/Kconfig +++ b/arch/mips/kvm/Kconfig @@ -20,6 +20,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select KVM_MMIO + select SRCU ---help--- Support for hosting Guest kernels. Currently supported on MIPS32 processors. diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 602eb51..af18e0f 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM select PREEMPT_NOTIFIERS select ANON_INODES select HAVE_KVM_EVENTFD + select SRCU config KVM_BOOK3S_HANDLER bool diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index 646db9c..5fce52c 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -28,6 +28,7 @@ config KVM select HAVE_KVM_IRQCHIP select HAVE_KVM_IRQFD select HAVE_KVM_IRQ_ROUTING + select SRCU ---help--- Support hosting paravirtualized guest machines using the SIE virtualization capability on the mainframe. This should work diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig index 2298cb1..1e968f7 100644 --- a/arch/tile/kvm/Kconfig +++ b/arch/tile/kvm/Kconfig @@ -21,6 +21,7 @@ config KVM depends on HAVE_KVM && MODULES select PREEMPT_NOTIFIERS select ANON_INODES + select SRCU ---help--- Support hosting paravirtualized guest machines. diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index f9d16ff..7dc7ba5 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -40,6 +40,7 @@ config KVM select HAVE_KVM_MSI select HAVE_KVM_CPU_RELAX_INTERCEPT select KVM_VFIO + select SRCU ---help--- Support hosting fully virtualized guest machines using hardware virtualization extensions. You will need a fairly recent diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 5bdedf6..c355a22 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -5,6 +5,7 @@ menuconfig MD bool "Multiple d
Re: [RFC PATCH] set_mb: Use smp_store_release() instead of set_mb()
On Wed, Nov 26, 2014 at 11:57 AM, Pranith Kumar wrote:
> set_mb() and smp_store_release() perform the same function. Also there are
> only
> a few users of set_mb(). We can convert these users to use smp_store_release()
> and delete the set_mb() definition.
>
> The following patch changes the users and if this is OK I will go ahead and
> delete the set_mb() definition. Comments and suggestions welcome.
>
> Thanks!
> Pranith
>
> Signed-off-by: Pranith Kumar
Please disregard this patch. I just realized that I read the code
wrong. Sorry for the noise.
Thanks!
> ---
> fs/select.c | 6 +++---
> include/linux/sched.h | 14 +++---
> kernel/futex.c| 4 ++--
> kernel/sched/wait.c | 4 ++--
> 4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/fs/select.c b/fs/select.c
> index 467bb1c..959a908 100644
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -189,7 +189,7 @@ static int __pollwake(wait_queue_t *wait, unsigned mode,
> int sync, void *key)
> * doesn't imply write barrier and the users expect write
> * barrier semantics on wakeup functions. The following
> * smp_wmb() is equivalent to smp_wmb() in try_to_wake_up()
> -* and is paired with set_mb() in poll_schedule_timeout.
> +* and is paired with smp_store_release() in poll_schedule_timeout.
> */
> smp_wmb();
> pwq->triggered = 1;
> @@ -244,7 +244,7 @@ int poll_schedule_timeout(struct poll_wqueues *pwq, int
> state,
> /*
> * Prepare for the next iteration.
> *
> -* The following set_mb() serves two purposes. First, it's
> +* The following smp_store_release() serves two purposes. First, it's
> * the counterpart rmb of the wmb in pollwake() such that data
> * written before wake up is always visible after wake up.
> * Second, the full barrier guarantees that triggered clearing
> @@ -252,7 +252,7 @@ int poll_schedule_timeout(struct poll_wqueues *pwq, int
> state,
> * this problem doesn't exist for the first iteration as
> * add_wait_queue() has full barrier semantics.
> */
> - set_mb(pwq->triggered, 0);
> + smp_store_release(pwq->triggered, 0);
>
> return rc;
> }
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8db31ef..4621d0b 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -253,7 +253,7 @@ extern char ___assert_task_state[1 - 2*!!(
> #define set_task_state(tsk, state_value) \
> do {\
> (tsk)->task_state_change = _THIS_IP_; \
> - set_mb((tsk)->state, (state_value));\
> + smp_store_release((tsk)->state, (state_value)); \
> } while (0)
>
> /*
> @@ -272,10 +272,10 @@ extern char ___assert_task_state[1 - 2*!!(
> current->task_state_change = _THIS_IP_; \
> current->state = (state_value); \
> } while (0)
> -#define set_current_state(state_value) \
> - do {\
> - current->task_state_change = _THIS_IP_; \
> - set_mb(current->state, (state_value)); \
> +#define set_current_state(state_value) \
> + do {\
> + current->task_state_change = _THIS_IP_; \
> + smp_store_release(current->state, (state_value)); \
> } while (0)
>
> #else
> @@ -283,7 +283,7 @@ extern char ___assert_task_state[1 - 2*!!(
> #define __set_task_state(tsk, state_value) \
> do { (tsk)->state = (state_value); } while (0)
> #define set_task_state(tsk, state_value) \
> - set_mb((tsk)->state, (state_value))
> + smp_store_release((tsk)->state, (state_value))
>
> /*
> * set_current_state() includes a barrier so that the write of current->state
> @@ -299,7 +299,7 @@ extern char ___assert_task_state[1 - 2*!!(
> #define __set_current_state(state_value) \
> do { current->state = (state_value); } while (0)
> #define set_current_state(state_value) \
> - set_mb(current->state, (state_value))
> + smp_store_release(current->state, (state_value))
>
> #endif
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 63678b5..0604355 100644
> --- a/kernel/fut
Re: [PATCH 3/3] btrfs: refactor btrfs_device->name updates
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval wrote:
> The rcu_string API introduced some new sparse errors but also revealed
> existing
> ones. First of all, the name in struct btrfs_device should be annotated as
> __rcu to prevent unsafe reads. Additionally, updates should go through
> rcu_dereference_protected to make it clear what's going on. This introduces
> some helper functions that factor out this functionality.
>
> Signed-off-by: Omar Sandoval
> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
> index 6e04f27..2298a70 100644
> --- a/fs/btrfs/volumes.h
> +++ b/fs/btrfs/volumes.h
> @@ -54,7 +54,7 @@ struct btrfs_device {
>
> struct btrfs_root *dev_root;
>
> - struct rcu_string *name;
> + struct rcu_string __rcu *name;
>
> u64 generation;
>
Since rcu_strings are rcu specific, why not annotate the char pointer
in 'struct rcu_string' with __rcu annotation? That should catch all
error-prone users of rcu_string.
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
