[RFC PATCH] security: Add a config option to disable security mitigations

[Pranith Kumar]

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

[Pranith Kumar]

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 line6 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 slides62 and63
> +   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

Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Pranith Kumar]

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 line6 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 slides62 and63
> +   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

[Pranith Kumar]

deference should actually be dereference.

Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com>
---
 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] Documentation/RCU: Fix minor typo

[Pranith Kumar]

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

[Pranith Kumar]

val is an unsigned int which makes the comparison >=0
unnecessary. This patch removes it.

Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com>
---
 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

[PATCH] scsi: Remove unnecessary comparison

[Pranith Kumar]

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

[Pranith Kumar]

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 tip/core/rcu 04/12] rcu: Move expedited code from tree.c to tree_exp.h

[Pranith Kumar]

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

[Pranith Kumar]

Hi Paolo,

Paolo Bonzini writes:

>
> Please test this instead:

This patch works for me. Please feel free to add:

Tested-by: Pranith Kumar <bobby.pr...@gmail.com>

>
> 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

Re: [PATCH] kvm: Fix build error caused by redefinition

[Pranith Kumar]

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

[Pranith Kumar]

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 <bobby.pr...@gmail.com>
---
 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(_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

[PATCH] kvm: Fix build error caused by redefinition

[Pranith Kumar]

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(_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

[Pranith Kumar]

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));
> 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: [PATCH] init: print warning message if /dev/console failed to open

[Pranith Kumar]

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));
> 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

[Pranith Kumar]

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

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

[Pranith Kumar]

On Tue, Jan 26, 2016 at 12:45 AM, Pranith Kumar <bobby.pr...@gmail.com> wrote:
> On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman <m...@ellerman.id.au> 
> 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

[Pranith Kumar]

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

qemu fails to build on 4.5-rc1

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

[Pranith Kumar]

On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman <m...@ellerman.id.au> 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

[Pranith Kumar]

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 <bobby.pr...@gmail.com>
---
 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

[Pranith Kumar]

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(>first);
-   for (;;) {
-   if (entry == NULL)
-   return NULL;
+   for (entry = smp_load_acquire(>first); entry ; ) {
old_entry = entry;
next = READ_ONCE(entry->next);
entry = cmpxchg(>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() initializer and conditional

[Pranith Kumar]

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 <bobby.pr...@gmail.com>
---
 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(>first);
-   for (;;) {
-   if (entry == NULL)
-   return NULL;
+   for (entry = smp_load_acquire(>first); entry ; ) {
old_entry = entry;
next = READ_ONCE(entry->next);
entry = cmpxchg(>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()

[Pranith Kumar]

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(>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/

[PATCH] llist: Use for conditional in llist_del_first()

[Pranith Kumar]

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 <bobby.pr...@gmail.com>
---
 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(>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 )

[Pranith Kumar]

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/

Re: bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )

[Pranith Kumar]

On Mon, Oct 12, 2015 at 1:04 AM, Jim Davis <jim.ep...@gmail.com> wrote:
> On Sun, Oct 11, 2015 at 7:58 PM, Pranith Kumar
> <bobby.prani+l...@gmail.com> 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 )

[Pranith Kumar]

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/

bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )

[Pranith Kumar]

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

[Pranith Kumar]

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/

[PATCH] doc: Clarify that nmi_watchdog param is for hardlockups

[Pranith Kumar]

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 <bobby.pr...@gmail.com>
---
 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

[Pranith Kumar]

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

[Pranith Kumar]

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/

[PATCH] x86: cmpxchg_double: Add missing memory clobber

[Pranith Kumar]

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 <bobby.pr...@gmail.com>
---
 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: [PATCH] x86: cmpxchg_double: Add missing memory clobber

[Pranith Kumar]

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/

Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

[Pranith Kumar]

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();'

-- 
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

[Pranith Kumar]

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: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

[Pranith Kumar]

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: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

[Pranith Kumar]

On Wed, Sep 2, 2015 at 11:23 AM, Pranith Kumar <bobby.pr...@gmail.com> 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();'

-- 
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: membarrier selftest issue

[Pranith Kumar]

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 

Re: membarrier selftest issue

[Pranith Kumar]

Hi Mathieu,

On Mon, Jun 15, 2015 at 11:31 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com 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 popt.h
  ^
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

Re: [PATCH] kernel:signal - Fix for typos in comments.

[Pranith Kumar]

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] kernel:signal - Fix for typos in comments.

[Pranith Kumar]

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 shailendra.capric...@gmail.com
 ---
  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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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] compiler-intel: fix wrong compiler barrier() macro

[Pranith Kumar]

On Wed, Apr 29, 2015 at 10:59 AM, mancha security manc...@zoho.com 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

[Pranith Kumar]

On Wed, Apr 29, 2015 at 12:59 PM, Daniel Borkmann dan...@iogearbox.net wrote:
 On 04/29/2015 06:40 PM, Pranith Kumar wrote:

 On Wed, Apr 29, 2015 at 10:59 AM, mancha security manc...@zoho.com
 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 bobby.pr...@gmail.com

-- 
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

[Pranith Kumar]

Hi Daniel,

On Wed, Apr 29, 2015 at 10:42 AM, Daniel Borkmann dan...@iogearbox.net 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)

[Pranith Kumar]

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)

[Pranith Kumar]

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 v16] sys_membarrier(): system-wide memory barrier (generic, x86)

[Pranith Kumar]

On Wed, Apr 22, 2015 at 4:40 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
 - Original Message -
 On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers
 mathieu.desnoy...@efficios.com 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)

[Pranith Kumar]

On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com 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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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 tip/core/rcu 05/12] rcutorture: Update configuration fragments for rcutree.rcu_fanout_exact

[Pranith Kumar]

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
 From: Paul E. McKenney paul...@linux.vnet.ibm.com

 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 paul...@linux.vnet.ibm.com

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/

Re: [PATCH tip/core/rcu 09/12] rcu: Break dependency of RCU_FANOUT_LEAF on RCU_FANOUT

[Pranith Kumar]

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
 From: Paul E. McKenney paul...@linux.vnet.ibm.com

 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 paul...@linux.vnet.ibm.com
 ---
  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 11/12] rcu: Make RCU able to tolerate undefined CONFIG_RCU_FANOUT_LEAF

[Pranith Kumar]

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com 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 0/12] RCU Kconfig fixes for v4.2

[Pranith Kumar]

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com 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 bobby.pr...@gmail.com

-- 
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

[Pranith Kumar]

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 bobby.pr...@gmail.com
---
 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

[Pranith Kumar]

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

[Pranith Kumar]

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/

Re: [PATCH] rcu: small rcu_dereference doc update

[Pranith Kumar]

On Fri, Apr 17, 2015 at 12:15 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com 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

[Pranith Kumar]

On Fri, Apr 17, 2015 at 6:33 AM, Milos Vyletel mi...@redhat.com 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 jeff.ha...@citrix.com
 Signed-off-by: Milos Vyletel mi...@redhat.com
 ---
  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

[Pranith Kumar]

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, then d

[PATCH] README: Update references to version 4

[Pranith Kumar]

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 bobby.pr...@gmail.com
---
 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, then do a make
+   kernel with -g; edit arch/x86

[PATCH] nouveau: gt215: Fix clock freq. calculation

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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 

Re: linux panic on 4.0.0-rc4

[Pranith Kumar]

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

[Pranith Kumar]

On Mon, Mar 16, 2015 at 11:18 PM, Peter Hurley pe...@hurleysoftware.com wrote:
 On 03/16/2015 11:12 PM, Pranith Kumar wrote:
 On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley pe...@hurleysoftware.com 
 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 pe...@hurleysoftware.com
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/

[PATCH] nouveau: gt215: Fix clock freq. calculation

[Pranith Kumar]

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 bobby.pr...@gmail.com
CC: sta...@vger.kernel.org
CC: Roy Spliet rspl...@eclipso.eu
CC: Ben Skeggs bske...@redhat.com
---
 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

[Pranith Kumar]

On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley pe...@hurleysoftware.com 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 1version 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, 

Re: linux panic on 4.0.0-rc4

[Pranith Kumar]

On Tue, Mar 17, 2015 at 4:13 PM, Peter Hurley pe...@hurleysoftware.com wrote:
 On 03/17/2015 04:07 PM, Pranith Kumar wrote:
 On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley pe...@hurleysoftware.com 
 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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman m...@ellerman.id.au 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

[Pranith Kumar]

On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley pe...@hurleysoftware.com 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

[Pranith Kumar]

On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman m...@ellerman.id.au wrote:
 On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote:
 On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar bobby.pr...@gmail.com 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

[Pranith Kumar]

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

[Pranith Kumar]

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

#
# 

linux panic on 4.0.0-rc4

[Pranith Kumar]

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

#
# Kernel 

Re: linux panic on 4.0.0-rc4

[Pranith Kumar]

On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar bobby.pr...@gmail.com 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
 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

[PATCH] audit: Remove condition which always evaluates to false

[Pranith Kumar]

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", _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/

[PATCH] audit: Remove condition which always evaluates to false

[Pranith Kumar]

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 bobby.pr...@gmail.com
---
 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

[Pranith Kumar]

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

[Pranith Kumar]

On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas catalin.mari...@arm.com 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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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

[Pranith Kumar]

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/

Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail

[Pranith Kumar]

On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas
catalin.mari...@arm.com 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/