Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00151.html
By the way, are there any GCC open project for volunteer beginners to
do in spare time.
Thanks in advance for your feedback,
Zhouyi
cxx_pretty_printer::type_id do not treat pointer to
pointer to member correctly.
this patch handle pointer to pointer to member according to
C++ standard 11.3.3.
I don't have write access to gcc.
Bootstrapped/regtested on x86_64-linux
Signed-off-by: Zhouyi Zhou
2018-12-04 Zhouyi
Hi,
Following patch has not been reviewed for two weeks. I think the
patch is trivial,
it doesn't affect other parts of GCC.
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01005.html
And I don't have write permission to GCC
Thanks
Zhouyi
On Mon, May 21, 2018 at 12:09 PM, Z
Hi
I think the comment in lower_eh_constructs_2 need a comma.
And I don't have write permission to GCC.
Bootstraped on x86-64
Thanks,
Zhouyi
Signed-off-by: Zhouyi Zhou
gcc/ChangeLog:
2018-05-21 Zhouyi Zhou
* tree-eh.c (lower_eh_constructs_2): Add a comma to co
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
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
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-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
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
perf stat -e instructions:u ../gcc/cc1plus g++.dg/template/friend28.C
59,171,598 instructions:u
bootstrapped and checked on x86-64
Signed-off-by: Zhouyi Zhou
---
gcc/cp/ChangeLog | 14 ++
gcc/cp/parser.c | 22 --
2 files changed, 30 insertions(+), 6 dele
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 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
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: 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
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
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
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
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
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
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
Currently, dpdk-pktgen will panic when assigning multi tx queues with pcap
packet, for example:
./app/app/build/pktgen -c f -n 2 -- -P -m "[0:1-3].0" -s 0:pcap/large.pcap
This patch fix this bug by assigning qid to memory pool name.
Signed-off-by: Zhouyi Zhou
---
app/pktgen-pcap.c
Thanks Vladimir for reviewing my patch.
> Thank you for the patch. The toplev.c part of the patch is ok for stage 1.
>
> As for reload1.c part, I don't see what you actually changed.
>
Please forgive my innocence, I have mistakenly thought the form-feed character
"^L" in line 415
is a type er
off-by: Zhouyi Zhou
---
gcc/ChangeLog | 9 +
gcc/reload1.c | 2 +-
gcc/toplev.c | 3 ++-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8d9a94d..9f78348 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2016-04-11 Zhouy
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
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
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
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
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.
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.
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 |
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 |
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
---
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
---
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
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
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,
> netdev@vger.kernel.org, linux-ker...@vger.kernel
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-devel@vger.kernel.org, coret...@netfilter.org,
> net...@vger.kernel.org, linux-ker...@vger.kernel
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...@v
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 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-devel@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
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
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 |
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 |
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
I can be of more beneficial :-)
Cheers
Zhouyi
> -Original Messages-
> From: "Vladimir Makarov"
> Sent Time: Thursday, June 25, 2015
> To: "Zhouyi Zhou" , gcc-patches@gcc.gnu.org
> Cc:
> Subject: Re: [PATCH IRA] save a bitmap check
>
> On 06
the end of that function).
Bootstrap and regtest scheduled on x86_64 GNU/Linux
Signed-off-by: Zhouyi Zhou
---
gcc/ChangeLog | 4
gcc/ira-color.c | 6 ++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d1f82b2..07605ae 100644
--- a
x27;s parent in current function context.
Thanks and Regards
Zhouyi
-- Forwarded message --
From: Zhouyi Zhou
Date: Thu, Mar 12, 2015 at 9:34 AM
Subject: [PATCH V2] IRA: Speed up setup_left_conflict_sizes_p
To: gcc-patches@gcc.gnu.org, richard.guent...@gmail.com
Cc: Zhouyi Zhou , Z
From: Zhouyi Zhou
In function setup_left_conflict_sizes_p, left conflict subnodes sizes
are computed in a bottom-to-up fashion through the regnodes foreast.
Speed up the process from prevent node itself to involve in this
computation.
I have no write access to GCC SVN repository, if it OK
From: Zhouyi Zhou
In function setup_left_conflict_sizes_p, left conflict subnodes sizes
are computed in a down-to-up fashion through the regnodes foreast.
Speed up the process from prevent node itself to involve in this
computation.
Bootstrap and regtest scheduled on x86_64 GNU/Linux
Signed
Linux
Signed-off-by: Zhouyi Zhou
---
gcc/ChangeLog |3 +++
gcc/ira-color.c |3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index bd74326..577b57e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,6 @@
+2015-02-09 Zhouyi
Thanks Jeff for reviewing,
I forget to mention that I do not have write access
to gcc.
Can you install for me ?
Cheers
Zhouyi
> -Original Messages-
> From: "Jeff Law"
> Sent Time: Tuesday, December 23, 2014
> To: "Zhouyi Zhou" , gcc-patches@gcc.gnu.or
Signed-off-by: Zhouyi Zhou
---
gcc/ChangeLog |5 +
gcc/ira-build.c |2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index e5d16f9..c0ce758 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-12-22 Zhouyi Zhou
From: Zhouyi Zhou
In function build_conflict_bit_table, id is set in objects_live before
traversing that sparseset, so the obj is unnessary compared with itself
during the traversing.
The comparing of obj with itself can be avoided by means of moving
sparseset_set_bit (objects_live, id
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
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
>> &
101 - 200 of 273 matches
Mail list logo
