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
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
Fix grammar error for comments above
process_bb_node_for_hard_reg_moves
Signed-off-by: Zhouyi Zhou
---
gcc/ira-costs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index 648806b..fbfb070 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira
> 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
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
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
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
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 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
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
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 +
>
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 +
>
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 +
>
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
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
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
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
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
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
he stmt is a gimple call node or a gimple phi node, it will never satisfy
the condition gimple_assign_single_p (stmt). so there exists redundant condition
checks. The patch attached try to remove this.
Bootstrap passed. Regression tested on x86_64-unknown-linux-gnu (pc).
ChangeLog:
2013-08-13 Zhou
Thanks for reviewing
On Tue, Jul 2, 2013 at 4:30 PM, Gleb Natapov wrote:
>
> On Tue, Jul 02, 2013 at 11:31:31AM +0800, Zhouyi Zhou wrote:
> > From: Zhouyi Zhou
> >
> > Currently the callers of emulator_read_write_onepage do not check the value
> > range
> >
From: Zhouyi Zhou
Currently the callers of emulator_read_write_onepage do not check the value
range
of the argument "bytes". If bytes is greater than the guest page size, many
unexpected things will happen.
This patch performs a check on the access size.
Tested on my x86_
Thanks Richard, nice adding, regression passed on my x86_64 GNU/Linux
On Wed, Apr 10, 2013 at 5:22 PM, Richard Biener
wrote:
> On Tue, Apr 9, 2013 at 5:10 PM, Zhouyi Zhou wrote:
>> Hi Richard,
>> I do not have write access to GCC SVN repository, can you commit it for me?
Hi Richard,
I do not have write access to GCC SVN repository, can you commit it for me?
Thanks alot
Cheers
On Tue, Apr 9, 2013 at 5:04 PM, Richard Biener
wrote:
>
> On Tue, Apr 9, 2013 at 5:40 AM, Zhouyi Zhou wrote:
> > On Mon, Apr 8, 2013 at 5:48 PM, Richard Biener
> >
on x86_64-linux
ChangeLog:
2013-04-08 Zhouyi Zhou
* cif-code.def (OVERWRITABLE): correct the comment for overwritable
function
* ipa-inline.c (can_inline_edge_p): let dump mechanism report the
inline
fail caused by overwritable functions.
* g
When inline failed because of callee is overwritable, gcc will not report it
in dump file (triggered by -fdump-tree-einline) as other not inlinable cases
do. This patch correct this.
Regtested/bootstrapped on x86_64-linux.
ChangeLog:
2013-04-08 Zhouyi Zhou
* cif-code.def
From: root
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
Tested on my x86_64 machine
Signed-off-by: Zhouyi Zhou
---
drivers/infiniband/hw/cxgb4/cm.c | 12
include/net/dst.h|6 --
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
I do a
/home/zzy/linux-stable#find . -name "*.c"|xargs grep -A 2 dst_neigh_lookup
and find that there are two places in drivers/infiniband/hw/cxgb4/cm.c
do not treat the error return of dst_neigh_lookup/dst_neigh_lookup_skb
Signed-off-by: Zhouyi Zhou gmail.com>
diff --git a/drive
://bugzilla.kernel.org/show_bug.cgi?id=54731)
This patch corrects above error with smallest changes to kernel source code.
Signed-off-by: Zhouyi Zhou
diff --git a/include/net/dst.h b/include/net/dst.h
index 853cda1..d594f8b 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -413,13 +413,15 @@ static inline
Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Jan 09 06:10:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Zhouyi Zhou
>Release:FreeBSD current
>Organization:
ICT CAS
>Environment:
FreeBSD host48 8.2-RELEASE Free
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sat Nov 10 09:40:02 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Zhouyi Zhou
>Release:FreeBSD current
>Organization:
ICT CAS
>Environment:
FreeBSD current
gt;nb_clusters = nb_clusters;
+m->inflight = 1;
out:
m->nb_available = MIN(nb_clusters << (s->cluster_bits - 9), n_end);
Thanks for investigation
Zhouyi
--
Zhouyi Zhou
ate-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Mar 17 04:00:23 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Zhouyi Zhou
>Release:FB 8.0
>Organization:
www.ict.ac.cn
>Environment:
FreeBSD 8.0-RELEASE FreeBSD 8
Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Oct 03 03:20:02 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Zhouyi Zhou
>Release:FreeBSD 8.0
>Organization:
Institute of Computing Technology, CAS
>Environment:
FreeBSD z
hi,
by google, I learn this problem has been exist for a long time.
but when I am doing
/mnt/ufs/usr#tar zcf src.tgz src
on a USB storage disk
The system issues:
umass0: BBB reset failed, TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
Dear All,
Any one know how to us netgraph to create a pair of pseudo ethernet
interface. The packet
go out from one and in another.
Thanks alot
Zhouyi Zhou
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
AIL PROTECTED]>
To: "zhouyi zhou" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2007 5:56 PM
Subject: Re: rewrite src/sys/i386/i386/in_cksum.c
Quoting zhouyi zhou <[EMAIL PROTECTED]> (from Mon, 9 Jul 2007
10:55:47 +0800):
> Hey,
>
"adcl %4, %0 \n"
+ "adcl $0, %0": "+r"(sum): "g" (((const unsigned int *)w)[0
/ 4]),
+"g" (((const unsigned int *)w)[4 / 4]),
+ "g" (((const unsigned int *)w)[8 / 4
(12);
413 MOP;
414 w += 8;
415 mlen -= 16;
416 }
On Mon, 9 Jul 2007 10:55:47 +0800
zhouyi zhou <[EMAIL PROTECTED]> wrote:
> Hey,
> Since FreeBSD update gcc from 3.4.x to 4.2.0, the FreeBSD gdb remote
tch
Thanks rdivacky @FreeBSD.org for encouraging me settle this bug.
Sincerely
Zhouyi Zhou
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
l in
a new function?
///
Finally
I owe greatly thanks for
various kind of suggestions not limited to above
Sincerely yours
Zhouyi Zhou
Insitute of Software
Chinese Academy of Sciences
___
fr
l in
a new function?
///
Finally
I owe greatly thanks for
various kind of suggestions not limited to above
Sincerely yours
Zhouyi Zhou
Insitute of Software
Chinese Academy of Sciences
___
freebsd-
It is state and surely not stat\e, sorry for the error :-)
On Tue, 29 May 2007 13:10:11 +0300
"Abdullah Ibn Hamad Al-Marri" <[EMAIL PROTECTED]> wrote:
> On 5/29/07, zhouyi zhou <[EMAIL PROTECTED]> wrote:
> > Dear Mr. Volker
> > Thank you very much
> >
Dear Mr. Volker
Thank you very much
Zelest persuade me add a "set skip on lo0".
That becomes:
set skip on lo0
pass in quick on rl0 proto tcp from any to any port=21 flags S/SA synproxy
stat\e
Sincerely yours
Zhouyi Zhou
On Tue, 29 May 2007 11:08:02 +0200
Volker <[EMAIL PROTECTED]&
high everyone
pass in quick on lo0 proto tcp from any to any port 21 flags S/SA synproxy state
the connection is established, but the control did not seams to pass to the ftpd___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/l
high everyone,( in pariticular Max :-))
The configuration line in my pf.conf is:
pass in quick on lo0 proto tcp from any to any port 21 flags S/SA synproxy
state
But:
the connection is established, but the control did not seams to pass to the
ftpd
Sincerely yours
Zhouyi Zhou
y machine is FreeBSD6.0 i686.
Sincerely yours
Zhouyi Zhou
Institute of Software
Chinese Academy of Sciences___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Hi, When I use FreeBSD-6.0 Release (also FreeBSD-5.4),
I found
IPSEC can't coexists with MAC.
When the IpSec is setup, and we connects the TCP
server with IPSEC and MAC support, the server
innevitably crack. Because the m_pkthdr of some mbuf
is mangled by unknown reasons.
Following is my kernel
Hi, When I use FreeBSD-6.0 Release (also FreeBSD-5.4),
I found
IPSEC can't coexists with MAC.
When the IpSec is setup, and we connects the TCP
server with IPSEC and MAC support, the server
innevitably crack. Because the m_pkthdr of some mbuf
is mangled by unknown reasons.
Following is my kernel
201 - 273 of 273 matches
Mail list logo
