The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 0c89d87d1d43d9fa268d1dc489518564d58bf497
Gitweb:
https://git.kernel.org/tip/0c89d87d1d43d9fa268d1dc489518564d58bf497
Author:Zhouyi Zhou
AuthorDate:Sat, 10 Apr 2021 15:35:23 +08:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 6494ccb93271bee596a12db32ff44867d5be2321
Gitweb:
https://git.kernel.org/tip/6494ccb93271bee596a12db32ff44867d5be2321
Author:Zhouyi Zhou
AuthorDate:Mon, 11 Jan 2021 09:08:59 +08:00
Committer
commit 40607ee97e4e ("preempt/dynamic: Provide irqentry_exit_cond_resched()
static call") tried to provide irqentry_exit_cond_resched() static call
in irqentry_exit, but has a typo in macro conditional statement.
This patch fix this typo.
Signed-off-by: Zhouyi Zhou
---
kernel/entr
During my study of RCU, I go through tree.c many times
and try to make some improvements to the comments.
Thanks a lot.
Signed-off-by: Zhouyi Zhou
---
kernel/rcu/tree.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel
visited), I think remove the surplus
instrumentation_end will make the code better.
Signed-off-by: Zhouyi Zhou
---
kernel/rcu/tree.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 40e5e3dd253e..eaec6f6032c2 100644
--- a/kernel/rcu/tree.c
+++ b
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 354c3f0e22dcb17c10d0b79f6e1c5ba286eec0b0
Gitweb:
https://git.kernel.org/tip/354c3f0e22dcb17c10d0b79f6e1c5ba286eec0b0
Author:Zhouyi Zhou
AuthorDate:Thu, 15 Oct 2020 03:53:03
Committer
There is a tiny typo in comment of function rcu_blocking_is_gp.
Signed-off-by: Zhouyi Zhou
---
kernel/rcu/tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f78ee75..4cca03f 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu
There is a tiny typo in comment of function kprobes_module_callback.
Signed-off-by: Zhouyi Zhou
---
kernel/kprobes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e995541..9d2042b 100644
--- a/kernel/kprobes.c
+++ b/kernel
Thanks for the tip!
On Thu, Oct 8, 2020 at 11:06 AM Randy Dunlap wrote:
>
> Hi,
>
> On 10/7/20 7:59 PM, Zhouyi Zhou wrote:
> > There is a tiny type error in comment of function kprobes_module_callback.
>
> Preferable
> typo
> and same in $Subject.
There is a tiny type error in comment of function kprobes_module_callback.
Signed-off-by: Zhouyi Zhou
---
kernel/kprobes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e995541..9d2042b 100644
--- a/kernel/kprobes.c
+++ b
ks even if all
corresponding CPUs offline")'
Consequently, rcu does not initiate RCU priority boosting on root rcu_node.
commit 1be0085b515e ("rcu: Don't initiate RCU priority boosting on root
rcu_node")'
So I think the comments for force_qs_rnp should be adjusted.
Thanks Paul's encouragement, I will keep studying SRCU code.
On Fri, Feb 23, 2018 at 9:20 AM, Paul E. McKenney
wrote:
> On Fri, Feb 23, 2018 at 09:04:05AM +0800, Zhouyi Zhou wrote:
>> Thanks Paul for reviewing
>
> And thank you for your interest in SRCU! I am pretty sure tha
Hi,
In function __ext4_grp_locked_error, __save_error_info(sb, function, line)
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. The reason, I guess
maybe it is
in locked state.
My question is why not m
m,
then we group the qlist_node according to their cache, so as not to
compare one by one to every qlist_node in the system.
Sorry for your time
Best Wishes
Zhouyi
On Wed, Nov 29, 2017 at 7:41 AM, Zhouyi Zhou wrote:
> Hi,
> I will try to reestablish the environment, and design proof
Hi,
I will try to reestablish the environment, and design proof of
concept of experiment.
Cheers
On Wed, Nov 29, 2017 at 1:57 AM, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov wrote:
>> On Tue, Nov 28, 2017 at 12:30 PM, Zhouyi Zhou wrote:
>>> H
place to drain because cache_free is fine in
that context. I am willing do it if you think it is convenient :-)
On Tue, Nov 28, 2017 at 5:27 PM, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 10:17 AM, Zhouyi Zhou wrote:
>> Hi,
>> Imagine all of the QUARANTINE
t 9:33 AM, Zhouyi Zhou wrote:
>> Hi,
>>Please take a look at function quarantine_put, I don't think following
>> code will limit the batch size below quarantine_batch_size. It only advance
>> quarantine_tail after qlist_move_all.
>>
>
ew_tail;
On Tue, Nov 28, 2017 at 4:12 PM, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 9:00 AM, Zhouyi Zhou wrote:
>> Thanks for reviewing
>>My machine has 128G of RAM, and runs many KVM virtual machines.
>> libvirtd always
>> report "internal error: receiv
v 28, 2017 at 3:45 PM, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 5:05 AM, Zhouyi Zhou wrote:
>> When there are huge amount of quarantined cache allocates in system,
>> number of entries in global_quarantine[i] will be great. Meanwhile,
>> there is no relax in while lo
.
On Tue, Nov 28, 2017 at 12:04 PM, wrote:
> 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 fil
commit 6807c84652b0 ("x86: Enable KASLR by default") enables KASLR
by default on x86. While KASLR will confuse gdb which resolve kernel
symbol address from symbol table of vmlinux. We should turn off KASLR for
kernel debugging.
Signed-off-by: Zhouyi Zhou
Reviewed-by: Kier
Hi Kieran,
Thanks for your review and invaluable advise, I will prepare a new
version immediately.
On Fri, Jul 7, 2017 at 4:05 PM, Kieran Bingham wrote:
> Hi Zhouyi
>
> Thankyou for the patch,
>
> On 07/07/17 08:14, Zhouyi Zhou wrote:
>> commit 6807c84652b0 ("x8
commit 6807c84652b0 ("x86: Enable KASLR by default") enables KASLR
by default on x86. While KASLR will confuse gdb which resolve kernel
symbol address from symbol table of vmlinux. We should turn off KASLR for
kernel debugging.
Signed-off-by: Zhouyi Zhou
---
Documentation/dev-tools/
commit 6807c84652b0 ("x86: Enable KASLR by default") enables KASLR
by default on x86. While KASLR will confuse gdb which resolve kernel
symbol address from symbol table of vmlinux. We should turn off KASLR for
kernel debugging.
Signed-off-by: Zhouyi Zhou
---
Documentation/dev-tool
Thanks Jeff for your advice,
Sorry for the my innocence as a Linux kernel rookie.
Zhouyi
On Thu, Dec 8, 2016 at 1:30 AM, Jeff Kirsher
wrote:
> On Wed, 2016-12-07 at 15:43 +0800, Zhouyi Zhou wrote:
>> Signed-off-by: Zhouyi Zhou
>> Reviewed-by: Cong Wang
>> Rev
Thanks Johannes for reviewing, your code is indeeded more elegant
On Wed, Dec 7, 2016 at 4:28 PM, Johannes Thumshirn wrote:
> Hi Zhouyi,
> On Wed, Dec 07, 2016 at 04:00:00PM +0800, Zhouyi Zhou wrote:
>> Return value of skb_linearize should be handled.
>>
>> Si
return value of skb_linearize should be handled
Signed-off-by: Zhouyi Zhou
Reviewed-by: Cong Wang
Reviewed-by: Yuval Shaia
Reviewed-by: Eric Dumazet
---
net/tipc/link.c | 3 ++-
net/tipc/name_distr.c | 5 -
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/tipc
Return value of skb_linearize should be handled.
Signed-off-by: Zhouyi Zhou
Reviewed-by: Yuval Shaia
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 6 --
drivers/scsi/fcoe/fcoe.c | 5 -
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
Signed-off-by: Zhouyi Zhou
Reviewed-by: Cong Wang
Reviewed-by: Yuval Shaia
Reviewed-by: Eric Dumazet
---
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 6 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net
Return value of skb_linearize should be handled in function
nes_netdev_start_xmit.
Compiled in x86_64
Signed-off-by: Zhouyi Zhou
Reviewed-by: Yuval Shaia
Reviewed-by: Eric Dumazet
---
drivers/infiniband/hw/nes/nes_nic.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
On Wed, Dec 7, 2016 at 1:02 PM, Cong Wang wrote:
> On Mon, Dec 5, 2016 at 11:10 PM, Zhouyi Zhou wrote:
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
>> index 2a653ec..ab787cb 100644
>> --- a/drive
kmalloc_reserve may fail to allocate memory inside skb_linearize,
which means skb_linearize's return value should not be ignored.
Following patch correct the uses of skb_linearize.
Compiled in x86_64
Signed-off-by: Zhouyi Zhou
---
drivers/infiniband/hw/nes/nes_nic.c
Hi,
Yesterday, I cced 5 patches to linux-kernel@vger.kernel.org using send-email,
but all of them were
rejected by mail server at vger.kernel.org as follows:
"Dear yizhouz...@ict.ac.cn, Your message to linux-kernel@vger.kernel.org was
rejected by the recipient domain. The error that the othe
Thanks Andrew for reviewing
> > In addition, give warning to users who forget to provide create file
> > hook.
>
> Why? What's the value in this?
>
> If the user didn't provide ->create_buf_file then setup_callbacks()
> will provide them with create_buf_file_default_callback() - what's
>
when relay_open_buf fails in relay_open, program will goto free_bufs,
but chan is nowhere freed.
In addition, give warning to users who forget to provide create file
hook.
Signed-off-by: Zhouyi Zhou
---
kernel/relay.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel
Thanks Pablo for reviewing
> From: "Pablo Neira Ayuso"
> Sent Time: Saturday, March 12, 2016
> To: "Zhouyi Zhou"
> On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote:
> > I think hackers chould build a malicious h323 packet to overflow
(iph->ih
and set addr functions.
Because the temporary h323 buffer is dynamiclly allocated, I remove
the h323 spin lock in my patch.
Signed-off-by: Zhouyi Zhou
---
include/linux/netfilter/nf_conntrack_h323.h | 17 +-
net/ipv4/netfilter/nf_nat_h323.c| 33 ++-
net/netfil
ted by Eric, this module is protected by a lock (nf_h323_lock)
so adding a variable h323_buffer_valid_bytes that would contain
the number of valid bytes would not require to change prototypes of
get_h2x5_addr.
Thanks Sergei for reviewing.
Signed-off-by: Zhouyi Zhou
---
net/netfil
ted by Eric, this module is protected by a lock (nf_h323_lock)
so adding a variable h323_buffer_valid_bytes that would contain
the number of valid bytes would not require to change prototypes of
get_h2x5_addr.
Signed-off-by: Zhouyi Zhou
---
net/netfilter/nf_conntrack_h323_main.c |
ble h323_buffer_valid_bytes that would contain
the number of valid bytes would not require to change prototypes of
get_h2x5_addr.
Signed-off-by: Zhouyi Zhou
---
net/netfilter/nf_conntrack_h323_main.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/net/netfil
ble h323_buffer_valid_bytes that would contain
the number of valid bytes would not require to change prototypes of
get_h2x5_addr.
Signed-off-by: Zhouyi Zhou
Signed-off-by: Eric Dumazet
Reviewed-by: Sergei Shtylyov
---
net/netfilter/nf_conntrack_h323_main.c | 13 +
1 file changed, 13 inserti
January 28, 2016
> To: "Zhouyi Zhou"
> Cc: eric.duma...@gmail.com, pa...@netfilter.org, ka...@trash.net,
> kad...@blackhole.kfki.hu, da...@davemloft.net,
> netfilter-de...@vger.kernel.org, coret...@netfilter.org,
> net...@vger.kernel.org, linux-ker...@vger.kernel
Thanks Eric for replying
> -Original Messages-
> From: "Eric Dumazet"
> Sent Time: Thursday, January 28, 2016
> To: "Zhouyi Zhou"
> Cc: pa...@netfilter.org, ka...@trash.net, kad...@blackhole.kfki.hu,
> da...@davemloft.net, netfilter-de...@vger.kern
Thanks Eric for your review and advice.
I think hackers chould build a malicious h323 packet to overflow
the pointer p which will panic during the memcpy(addr, p, len)
For example, he may fabricate a very large taddr->ipAddress.ip;
Signed-off-by: Zhouyi Zhou
---
net/netfil
From: Zhouyi Zhou
I think hackers chould build a malicious h323 packet to overflow
the pointer p which will panic during the memcpy(addr, p, len)
For example, he may fabricate a very large taddr->ipAddress.ip;
Signed-off-by: Zhouyi Zhou
---
net/netfilter/nf_conntrack_h323_main.c |
save some CPU
cycles because the compilers won't do it (the callee
is defined in another compiling unit, so it can't be inlined).
Signed-off-by: Zhouyi Zhou
---
drivers/acpi/acpica/psobject.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/acpi/acpica/ps
In function acpi_ns_one_complete_parse, the variable declaration
aml_length is not correctly indented.
Signed-off-by: Zhouyi Zhou
---
drivers/acpi/acpica/nsparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/nsparse.c b/drivers/acpi/acpica/nsparse.c
Use HAVE_JUMP_LABEL as elsewhere in the kernel to ensure
that the toolchain has the required support in addition to
CONFIG_JUMP_LABEL being set.
Signed-off-by: Zhouyi Zhou
Reviewed-by: Florian Westphal
---
include/linux/netfilter.h |5 +++--
net/netfilter/core.c |6 +++---
2
Thanks Florian for reviewing
> -Original Messages-
> From: "Florian Westphal"
>
> Zhouyi Zhou wrote:
> >
> > CONFIG_JUMP_LABEL doesn't ensure HAVE_JUMP_LABEL, if it
> > is not the case use maintainers's own mutex to guard
> > th
Thanks Jason for reviewing it
> -Original Messages-
> From: "Jason Baron"
> Sent Time: Thursday, August 21, 2014
> To: "Zhouyi Zhou"
> Cc: drjo...@redhat.com, konrad.w...@oracle.com,
> raghavendra...@linux.vnet.ibm.com, mi...@k
CONFIG_JUMP_LABEL doesn't ensure HAVE_JUMP_LABEL, if it
is not the case use maintainers's own mutex to guard
the modification of global values.
Signed-off-by: Zhouyi Zhou
---
include/linux/netfilter.h |5 +++--
net/netfilter/core.c |6 +++---
2 files changed, 6 insert
CONFIG_JUMP_LABEL doesn't ensure HAVE_JUMP_LABEL, if it
is not the case use maintainers's own mutex to guard
the modification of global values.
Signed-off-by: Zhouyi Zhou
---
arch/powerpc/platforms/powernv/opal-tracepoints.c |2 +-
arch/powerpc/platforms/pseries/lpar.c
jump_label_ratelimit.h is split from jump_label.h to enable the
includers who don't want linux/workqueue.h.
As HAVE_JUMP_LABEL is only defined in jump_label.h, will following
patch makes jump_labe_ratelimit.h more tidy?
Compiled and Tested in x86_64
Signed-off-by: Zhouyi Zhou
---
in
Thanks for reviewing.
I did miss it.
> -Original Messages-
> From: "Dmitry Popov"
> Sent Time: Wednesday, July 30, 2014
> To: "Zhouyi Zhou"
> Cc: rdun...@infradead.org, da...@davemloft.net, mini...@googlemail.com,
> bro...@redhat.com, steffen.klas
I think it is useful to add ttl option for pktgen, for example
if a some ISP want to test its network quality, it could set
ttl so that the tested links get the packet while end users won't
get it.
Also, add a blank line after declarations in pktgen.c
Signed-off-by: Zhouyi
Commit-ID: 503d3291a937b726757c1f7c45fa02389d2f4324
Gitweb: http://git.kernel.org/tip/503d3291a937b726757c1f7c45fa02389d2f4324
Author: Zhouyi Zhou
AuthorDate: Wed, 11 Jun 2014 12:09:03 +0800
Committer: Ingo Molnar
CommitDate: Wed, 16 Jul 2014 13:31:06 +0200
perf/x86/amd: Try to fix
According to Peter, Thomas, Joe and David's advices, try fixing all memory
allocation
failure handling in tlb_uv.c
compiled in x86_64
Signed-off-by: Zhouyi Zhou
---
arch/x86/platform/uv/tlb_uv.c | 122 +
1 file changed, 87 insertions(+), 35 dele
Signed-off-by: Zhouyi Zhou
---
arch/x86/kernel/cpu/perf_event_amd_uncore.c | 32 +++
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_uncore.c
b/arch/x86/kernel/cpu/perf_event_amd_uncore.c
index 3bbdf4c..f60a50e 100644
According to Peter's advice, put the failure handling to a goto chain.
Compiled in x86_64, could you check if there is anything that I missed.
Signed-off-by: Zhouyi Zhou
---
arch/x86/kernel/cpu/perf_event_amd_uncore.c | 111 ---
1 file changed, 84 insertions(+
Thanks for reviewing, I will work on a new version
On Wed, Jun 11, 2014 at 7:28 AM, Thomas Gleixner wrote:
> On Tue, 10 Jun 2014, H. Peter Anvin wrote:
>
>> On 06/10/2014 12:35 AM, Zhouyi Zhou wrote:
>> > Fixing some memory allocation failure handling in x86 UV
>> &
This is version 2.0 of "[PATCH 1/1] perf/amd: NULL return of kzalloc_node
should be handled"
(http://www.spinics.net/lists/kernel/msg1760689.html),
Try to correctly handle mem allocation failure in perf_event_amd_uncore.c
Signed-off-by: Zhouyi Zhou
---
arch/x86/
-ENODEV?
On Tue, Jun 10, 2014 at 4:22 PM, Peter Zijlstra wrote:
> On Tue, Jun 10, 2014 at 03:37:38PM +0800, Zhouyi Zhou wrote:
>
> Less typing more thinking, this is wrong. You should fail when the
> allocation fails.
--
To unsubscribe from this list: send the line "unsubscribe
Signed-off-by: Zhouyi Zhou
---
arch/x86/kernel/cpu/perf_event_amd_uncore.c | 32 +++
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_uncore.c
b/arch/x86/kernel/cpu/perf_event_amd_uncore.c
index 3bbdf4c..f60a50e 100644
Fixing some memory allocation failure handling in x86 UV
Signed-off-by: Zhouyi Zhou
---
arch/x86/platform/uv/tlb_uv.c | 17 +
1 file changed, 18 insertions(+)
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index dfe605a..a434768 100644
--- a/arch
NULL return of kzalloc_node should be handled
Signed-off-by: Zhouyi Zhou
---
arch/powerpc/platforms/pseries/iommu.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
> You could just force pktgen to not support multi-skb on vlan interfaces?
>
> I thought we went through this a year or two ago and came up with
> something like a 'pktgen-challenged' network interface flag?
Ah yes, IFF_TX_SKB_SHARING does the job, very sorry for missing that,
as matter of fact,
Thank Sergei for reviewing.
I think
On Sat, May 3, 2014 at 12:18 AM, Sergei Shtylyov
wrote:
>> +
>> + if (pkt_dev->clone_skb && is_vlan_dev(odev)) {
>> + nskb = skb_clone(pkt_dev->skb, GFP_ATOMIC);
>> + ret = -ENOMEM;
>> + if (nskb)
>> +
Thanks for reviewing
On Fri, May 2, 2014 at 10:00 PM, John Fastabend
wrote:
> On 5/2/2014 6:19 AM, Jesper Dangaard Brouer wrote:
>>
>> On Fri, 2 May 2014 15:18:12 +0800
>> Zhouyi Zhou wrote:
>>
>>> As http://www.spinics.net/lists/netdev/msg165015.html
>&g
As http://www.spinics.net/lists/netdev/msg165015.html
pktgen generates shared packet through vlan interface will cause
oops because of duplicate entering tc queue.
Try to solve this problem by means of packet clone instead of sharing.
Signed-off-by: Zhouyi Zhou
---
net/core/pktgen.c | 20
Delicate design! thanks for replying, sorry for the trouble
On Tue, Mar 18, 2014 at 9:34 PM, Gerald Schaefer
wrote:
> On Tue, 18 Mar 2014 09:24:55 +0800
> Zhouyi Zhou wrote:
>
>> Thanks Gerald for reviewing and sorry for not elaborated it in the e-mail.
>>
>> Firs
aefer
wrote:
> On Sat, 15 Mar 2014 21:35:40 +0800
> Zhouyi Zhou wrote:
>
>> correct misuses of module_put in appldata_generic_handler
>
> Sorry, I don't see any misuse, could you elaborate?
>
>>
>> Signed-off-by: Zhouyi Zhou
>> ---
>> arch/s
correct misuses of module_put in appldata_generic_handler
Signed-off-by: Zhouyi Zhou
---
arch/s390/appldata/appldata_base.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/s390/appldata/appldata_base.c
b/arch/s390/appldata/appldata_base.c
index 47c8630..683e0282 100644
--- a/arch
an idea that could we pack the seldom changed members
(nf_ct_proto included) to a structure and we allocated it from a
cache aligned slub when the structure "net" is initialized.
Zhouyi
On Wed, Mar 12, 2014 at 5:36 PM, David Laight wrote:
> From: Zhouyi Zhou
>> not
not frequently changing components should share same cachelines
Signed-off-by: Zhouyi Zhou
---
include/net/netns/conntrack.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/net/netns/conntrack.h b/include/net/netns/conntrack.h
index fbcc7fa..69d2d58
From: Zhouyi Zhou
iopte free should check wether input argument is NULL because kmem_cache_free
will panic on NULL argument
Signed-off-by: Zhouyi Zhou
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a
From: Zhouyi Zhou
On Tue, 4 Mar 2014 16:41:18 +0100
Joerg Roedel wrote:
> On Tue, Feb 11, 2014 at 10:12:53AM +0800, Zhouyi Zhou wrote:
> > From: Zhouyi Zhou
> >
> > The function iopte_alloc do not check NULL return of kmem_cache_zalloc,
> > call iopte_free
From: Zhouyi Zhou
The function iopte_alloc do not check NULL return of kmem_cache_zalloc,
call iopte_free with argument 0 will panic.
Signed-off-by: Zhouyi Zhou
---
drivers/iommu/omap-iommu.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b
double the x86_64 kernel stack size?
Signed-off-by: Zhouyi Zhou
Tested-by: Zhouyi Zhou
---
arch/x86/include/asm/page_64_types.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 43dcd80
NULL return of kmem_cache_zalloc should be handled in jffs2_alloc_xattr_datum
and jff2_alloc_xattr_ref.
Signed-off-by: Zhouyi Zhou
---
fs/jffs2/malloc.c |4
1 file changed, 4 insertions(+)
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index 4f47aa2..b8fd651 100644
--- a/fs/jffs2
if iopte is NULL, iopte_free should not be called.
Signed-off-by: Zhouyi Zhou
---
drivers/iommu/omap-iommu.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..5155714 100644
--- a/drivers/iommu/omap
NULL return of kvmppc_mmu_hpte_cache_next should be handled
Signed-off-by: Zhouyi Zhou
---
arch/powerpc/kvm/book3s_32_mmu_host.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 3a0abd2..5fac89d
ping
> 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 +
>
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
Commit-ID: 8e50d384cc1d5afd2989cf0f7093756ed7164eb2
Gitweb: http://git.kernel.org/tip/8e50d384cc1d5afd2989cf0f7093756ed7164eb2
Author: Zhouyi Zhou
AuthorDate: Thu, 24 Oct 2013 15:43:33 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 28 Oct 2013 16:06:00 -0300
perf tools
ote:
> Em Thu, Oct 24, 2013 at 03:43:33PM +0800, Zhouyi Zhou escreveu:
>>
>> The tail position of the event buffer should only be
>> modified after actually use that event. If not the event
>> buffer could be invalid before use, and segment fault occurs when invoking
The tail position of the event buffer should only be
modified after actually use that event. If not the event
buffer could be invalid before use, and segment fault occurs when invoking
perf top -G.
Signed-off-by: Zhouyi Zhou
---
tools/perf/builtin-kvm.c |4
tools
86 matches
Mail list logo