[PATCH] RCU: Adjust the comment of function rcu_is_watching

[zhouzhouyi]

From: Zhouyi Zhou 

Because RCU avoids interrupting idle CPUs, rcu_is_watching is used to
test whether or not it is currently legal to run RCU read-side 
critical sections on this CPU. 

First sentence and last sentence of current comment for rcu_is_watching
have opposite meaning of what is expected.  

Signed-off-by: Zhouyi Zhou 
---
 kernel/rcu/tree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1..adb04ea 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1010,12 +1010,12 @@ void rcu_irq_enter_irqson(void)
 }
 
 /**
- * rcu_is_watching - see if RCU thinks that the current CPU is idle
+ * rcu_is_watching - see if RCU thinks that the current CPU is not idle
  *
  * Return true if RCU is watching the running CPU, which means that this
  * CPU can safely enter RCU read-side critical sections.  In other words,
- * if the current CPU is in its idle loop and is neither in an interrupt
- * or NMI handler, return true.
+ * if the current CPU is not in its idle loop or is in an interrupt or
+ * NMI handler, return true.
  */
 bool notrace rcu_is_watching(void)
 {
-- 
2.1.4

[PATCH] RCU: Adjust the comment of function rcu_is_watching

[zhouzhouyi]

From: Zhouyi Zhou 

Because RCU avoids interrupting idle CPUs, rcu_is_watching is used to
test whether or not it is currently legal to run RCU read-side 
critical sections on this CPU. 

First sentence and last sentence of current comment for rcu_is_watching
have opposite meaning of what is expected.  

Signed-off-by: Zhouyi Zhou 
---
 kernel/rcu/tree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1..adb04ea 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1010,12 +1010,12 @@ void rcu_irq_enter_irqson(void)
 }
 
 /**
- * rcu_is_watching - see if RCU thinks that the current CPU is idle
+ * rcu_is_watching - see if RCU thinks that the current CPU is not idle
  *
  * Return true if RCU is watching the running CPU, which means that this
  * CPU can safely enter RCU read-side critical sections.  In other words,
- * if the current CPU is in its idle loop and is neither in an interrupt
- * or NMI handler, return true.
+ * if the current CPU is not in its idle loop or is in an interrupt or
+ * NMI handler, return true.
  */
 bool notrace rcu_is_watching(void)
 {
-- 
2.1.4

[PATCH] srcu: remove never used variable

[zhouzhouyi]

From: Zhouyi Zhou 

In function srcu_gp_end, the variable idxnext is never used after assign,
remove it and its assign statement.

Signed-off-by: Zhouyi Zhou 
---
 kernel/rcu/srcutree.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index d5cea81..1241715 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -531,7 +531,6 @@ static void srcu_gp_end(struct srcu_struct *sp)
unsigned long flags;
unsigned long gpseq;
int idx;
-   int idxnext;
unsigned long mask;
struct srcu_data *sdp;
struct srcu_node *snp;
@@ -555,7 +554,6 @@ static void srcu_gp_end(struct srcu_struct *sp)
 
/* Initiate callback invocation as needed. */
idx = rcu_seq_ctr(gpseq) % ARRAY_SIZE(snp->srcu_have_cbs);
-   idxnext = (idx + 1) % ARRAY_SIZE(snp->srcu_have_cbs);
rcu_for_each_node_breadth_first(sp, snp) {
spin_lock_irq_rcu_node(snp);
cbs = false;
-- 
2.1.4

[PATCH] srcu: remove never used variable

[zhouzhouyi]

From: Zhouyi Zhou 

In function srcu_gp_end, the variable idxnext is never used after assign,
remove it and its assign statement.

Signed-off-by: Zhouyi Zhou 
---
 kernel/rcu/srcutree.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index d5cea81..1241715 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -531,7 +531,6 @@ static void srcu_gp_end(struct srcu_struct *sp)
unsigned long flags;
unsigned long gpseq;
int idx;
-   int idxnext;
unsigned long mask;
struct srcu_data *sdp;
struct srcu_node *snp;
@@ -555,7 +554,6 @@ static void srcu_gp_end(struct srcu_struct *sp)
 
/* Initiate callback invocation as needed. */
idx = rcu_seq_ctr(gpseq) % ARRAY_SIZE(snp->srcu_have_cbs);
-   idxnext = (idx + 1) % ARRAY_SIZE(snp->srcu_have_cbs);
rcu_for_each_node_breadth_first(sp, snp) {
spin_lock_irq_rcu_node(snp);
cbs = false;
-- 
2.1.4

[PATCH] FS: EXT4: syn error in __ext4_grp_locked_error

[zhouzhouyi]

From: Zhouyi Zhou 

In function __ext4_grp_locked_error,   __save_error_info
is called to save error info in super block block, but does not sync
that information to disk to info the subsequence fsck after reboot.

This patch sync the error information to disk. After this patch,
I think there is no obvious EXT4 error handle branche which leads to
"Remounting filesystem read-only" will leave the disk partition miss
the subsequence fsck.

Compiled in x86_64 Linux
Signed-off-by: Zhouyi Zhou 
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 7c46693..7159438 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -742,6 +742,7 @@ __acquires(bitlock)
}
 
ext4_unlock_group(sb, grp);
+   ext4_commit_super(sb, 1);
ext4_handle_error(sb);
/*
 * We only get here in the ERRORS_RO case; relocking the group
-- 
2.1.4

[PATCH] FS: EXT4: syn error in __ext4_grp_locked_error

[zhouzhouyi]

From: Zhouyi Zhou 

In function __ext4_grp_locked_error,   __save_error_info
is called to save error info in super block block, but does not sync
that information to disk to info the subsequence fsck after reboot.

This patch sync the error information to disk. After this patch,
I think there is no obvious EXT4 error handle branche which leads to
"Remounting filesystem read-only" will leave the disk partition miss
the subsequence fsck.

Compiled in x86_64 Linux
Signed-off-by: Zhouyi Zhou 
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 7c46693..7159438 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -742,6 +742,7 @@ __acquires(bitlock)
}
 
ext4_unlock_group(sb, grp);
+   ext4_commit_super(sb, 1);
ext4_handle_error(sb);
/*
 * We only get here in the ERRORS_RO case; relocking the group
-- 
2.1.4

[PATCH 1/1] kasan: fix livelock in qlist_move_cache

[zhouzhouyi]

From: Zhouyi Zhou 

This patch fix livelock by conditionally release cpu to let others
has a chance to run.

Tested on x86_64.
Signed-off-by: Zhouyi Zhou 
---
 mm/kasan/quarantine.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 3a8ddf8..33eeff4 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -265,10 +265,13 @@ static void qlist_move_cache(struct qlist_head *from,
   struct kmem_cache *cache)
 {
struct qlist_node *curr;
+   struct qlist_head tmp_head;
+   unsigned long flags;
 
if (unlikely(qlist_empty(from)))
return;
 
+   qlist_init(_head);
curr = from->head;
qlist_init(from);
while (curr) {
@@ -278,10 +281,17 @@ static void qlist_move_cache(struct qlist_head *from,
if (obj_cache == cache)
qlist_put(to, curr, obj_cache->size);
else
-   qlist_put(from, curr, obj_cache->size);
+   qlist_put(_head, curr, obj_cache->size);
 
curr = next;
+
+   if (need_resched()) {
+   spin_unlock_irqrestore(_lock, flags);
+   cond_resched();
+   spin_lock_irqsave(_lock, flags);
+   }
}
+   qlist_move_all(_head, from);
 }
 
 static void per_cpu_remove_cache(void *arg)
-- 
2.1.4

[PATCH 1/1] kasan: fix livelock in qlist_move_cache

[zhouzhouyi]

From: Zhouyi Zhou 

This patch fix livelock by conditionally release cpu to let others
has a chance to run.

Tested on x86_64.
Signed-off-by: Zhouyi Zhou 
---
 mm/kasan/quarantine.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 3a8ddf8..33eeff4 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -265,10 +265,13 @@ static void qlist_move_cache(struct qlist_head *from,
   struct kmem_cache *cache)
 {
struct qlist_node *curr;
+   struct qlist_head tmp_head;
+   unsigned long flags;
 
if (unlikely(qlist_empty(from)))
return;
 
+   qlist_init(_head);
curr = from->head;
qlist_init(from);
while (curr) {
@@ -278,10 +281,17 @@ static void qlist_move_cache(struct qlist_head *from,
if (obj_cache == cache)
qlist_put(to, curr, obj_cache->size);
else
-   qlist_put(from, curr, obj_cache->size);
+   qlist_put(_head, curr, obj_cache->size);
 
curr = next;
+
+   if (need_resched()) {
+   spin_unlock_irqrestore(_lock, flags);
+   cond_resched();
+   spin_lock_irqsave(_lock, flags);
+   }
}
+   qlist_move_all(_head, from);
 }
 
 static void per_cpu_remove_cache(void *arg)
-- 
2.1.4

[PATCH RFC] ACPI: (x86) remove useless initial assignment in gsi_to_irq

[zhouzhouyi]

From: Zhouyi Zhou 

I think in function gsi_to_irq, initial assignment to irq is useless although 
compiler
may eliminate it during the compilng. 

Signed-off-by: Zhouyi Zhou 
---
 arch/x86/kernel/acpi/boot.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1dac942..b93d61e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -103,7 +103,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
 
 static unsigned int gsi_to_irq(unsigned int gsi)
 {
-   unsigned int irq = gsi + NR_IRQS_LEGACY;
+   unsigned int irq;
unsigned int i;
 
for (i = 0; i < NR_IRQS_LEGACY; i++) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] ACPI: (x86) remove useless initial assignment in gsi_to_irq

[zhouzhouyi]

From: Zhouyi Zhou zhouzho...@gmail.com

I think in function gsi_to_irq, initial assignment to irq is useless although 
compiler
may eliminate it during the compilng. 

Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn
---
 arch/x86/kernel/acpi/boot.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1dac942..b93d61e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -103,7 +103,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
 
 static unsigned int gsi_to_irq(unsigned int gsi)
 {
-   unsigned int irq = gsi + NR_IRQS_LEGACY;
+   unsigned int irq;
unsigned int i;
 
for (i = 0; i  NR_IRQS_LEGACY; i++) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

re: ping: re:[PATCH 1/1] kernel code that do not handle NULL return of kmem_cache_zalloc

[zhouzhouyi]

From: Zhouyi Zhou 

the text of previous ping message maybe garbled sorry for the trouble

> I do a grep for kmem_cache_zalloc and kmem_cache_alloc
> in kernel tree, and find some code do not handle NULL
> return of kmem_cache_zalloc correctly


> Signed-off-by: Zhouyi Zhou 
---
 arch/powerpc/kvm/book3s_32_mmu_host.c |5 +
 drivers/iommu/omap-iommu.c|3 ++-
 fs/jffs2/malloc.c |4 
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c 
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 3a0abd2..5fac89d 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -243,6 +243,11 @@ next_pteg:
/* Now tell our Shadow PTE code about the new page */
 
pte = kvmppc_mmu_hpte_cache_next(vcpu);
+   if (!pte) {
+   kvm_release_pfn_clean(hpaddr >> PAGE_SHIFT);
+   r = -EAGAIN;
+   goto out;
+   }
 
dprintk_mmu("KVM: %c%c Map 0x%llx: [%lx] 0x%llx (0x%llx) -> %lx\n",
orig_pte->may_write ? 'w' : '-',
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..5155714 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -551,7 +551,8 @@ static u32 *iopte_alloc(struct omap_iommu *obj, u32 *iopgd, 
u32 da)
dev_vdbg(obj->dev, "%s: a new pte:%p\n", __func__, iopte);
} else {
/* We raced, free the reduniovant table */
-   iopte_free(iopte);
+   if (iopte)
+   iopte_free(iopte);
}
 
 pte_ready:
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index 4f47aa2..58e2336 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2/malloc.c
@@ -287,6 +287,8 @@ struct jffs2_xattr_datum *jffs2_alloc_xattr_datum(void)
 {
struct jffs2_xattr_datum *xd;
xd = kmem_cache_zalloc(xattr_datum_cache, GFP_KERNEL);
+   if (!xd)
+   return NULL;
dbg_memalloc("%p\n", xd);
 
xd->class = RAWNODE_CLASS_XATTR_DATUM;
@@ -305,6 +307,8 @@ struct jffs2_xattr_ref *jffs2_alloc_xattr_ref(void)
 {
struct jffs2_xattr_ref *ref;
ref = kmem_cache_zalloc(xattr_ref_cache, GFP_KERNEL);
+   if (!ref)
+   return NULL;
dbg_memalloc("%p\n", ref);
 
ref->class = RAWNODE_CLASS_XATTR_REF;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

re: ping: re:[PATCH 1/1] kernel code that do not handle NULL return of kmem_cache_zalloc

[zhouzhouyi]

From: Zhouyi Zhou zhouzho...@gmail.com

the text of previous ping message maybe garbled sorry for the trouble

 I do a grep for kmem_cache_zalloc and kmem_cache_alloc
 in kernel tree, and find some code do not handle NULL
 return of kmem_cache_zalloc correctly


 Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn
---
 arch/powerpc/kvm/book3s_32_mmu_host.c |5 +
 drivers/iommu/omap-iommu.c|3 ++-
 fs/jffs2/malloc.c |4 
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c 
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 3a0abd2..5fac89d 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -243,6 +243,11 @@ next_pteg:
/* Now tell our Shadow PTE code about the new page */
 
pte = kvmppc_mmu_hpte_cache_next(vcpu);
+   if (!pte) {
+   kvm_release_pfn_clean(hpaddr  PAGE_SHIFT);
+   r = -EAGAIN;
+   goto out;
+   }
 
dprintk_mmu(KVM: %c%c Map 0x%llx: [%lx] 0x%llx (0x%llx) - %lx\n,
orig_pte-may_write ? 'w' : '-',
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..5155714 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -551,7 +551,8 @@ static u32 *iopte_alloc(struct omap_iommu *obj, u32 *iopgd, 
u32 da)
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
/* We raced, free the reduniovant table */
-   iopte_free(iopte);
+   if (iopte)
+   iopte_free(iopte);
}
 
 pte_ready:
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index 4f47aa2..58e2336 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2/malloc.c
@@ -287,6 +287,8 @@ struct jffs2_xattr_datum *jffs2_alloc_xattr_datum(void)
 {
struct jffs2_xattr_datum *xd;
xd = kmem_cache_zalloc(xattr_datum_cache, GFP_KERNEL);
+   if (!xd)
+   return NULL;
dbg_memalloc(%p\n, xd);
 
xd-class = RAWNODE_CLASS_XATTR_DATUM;
@@ -305,6 +307,8 @@ struct jffs2_xattr_ref *jffs2_alloc_xattr_ref(void)
 {
struct jffs2_xattr_ref *ref;
ref = kmem_cache_zalloc(xattr_ref_cache, GFP_KERNEL);
+   if (!ref)
+   return NULL;
dbg_memalloc(%p\n, ref);
 
ref-class = RAWNODE_CLASS_XATTR_REF;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1 v1] the recommended crash memory reservation is too small for x86_64.

[zhouzhouyi]

From: root 


 On Documentation/kdump/kdump.txt, section Boot into  System Kernel: On x86 and 
x86_64, use
 "crashkernel=64M@16M", but some OSes like ubuntu 12.10 use ram fs larger than 
64M, so in these cases the
 memory reserved for crashkernel should be at least 128M.


Signed-off-by: Zhouyi Zhou 
---
 Documentation/kdump/kdump.txt |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa0..1e850e0 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -290,7 +290,9 @@ Boot into System Kernel
"crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
starting at physical address 0x0100 (16MB) for the dump-capture kernel.
 
-   On x86 and x86_64, use "crashkernel=64M@16M".
+   On x86 and x86_64, use "crashkernel=64M@16M" (some OSes use init ram fs 
larger
+than 64M, for example ubuntu-12.10, use crashkernel=128M@16M instead, or 
dump-capture
+kernel will out of memory).
 
On ppc64, use "crashkernel=128M@32M".
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1 v1] the recommended crash memory reservation is too small for x86_64.

[zhouzhouyi]

From: root root@zzy-Lenovo.(none)


 On Documentation/kdump/kdump.txt, section Boot into  System Kernel: On x86 and 
x86_64, use
 crashkernel=64M@16M, but some OSes like ubuntu 12.10 use ram fs larger than 
64M, so in these cases the
 memory reserved for crashkernel should be at least 128M.


Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn
---
 Documentation/kdump/kdump.txt |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa0..1e850e0 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -290,7 +290,9 @@ Boot into System Kernel
crashkernel=64M@16M tells the system kernel to reserve 64 MB of memory
starting at physical address 0x0100 (16MB) for the dump-capture kernel.
 
-   On x86 and x86_64, use crashkernel=64M@16M.
+   On x86 and x86_64, use crashkernel=64M@16M (some OSes use init ram fs 
larger
+than 64M, for example ubuntu-12.10, use crashkernel=128M@16M instead, or 
dump-capture
+kernel will out of memory).
 
On ppc64, use crashkernel=128M@32M.
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/