[tip: sched/urgent] preempt/dynamic: Fix typo in macro conditional statement

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

[tip: core/rcu] rcu: Remove spurious instrumentation_end() in rcu_nmi_enter()

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

[PATCH] preempt/dynamic: fix typo in macro conditional statement

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

[PATCH] RCU: some improvements to comments of tree.c

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

[PATCH] rcu: remove surplus instrumentation_end in rcu_nmi_enter

as 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

[tip: core/rcu] rcu: Fix a typo in rcu_blocking_is_gp() header comment

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

[PATCH] RCU: fix a typo in comments of rcu_blocking_is_gp

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

[PATCH V2] kprobes: Correct a typo in function kprobes_module_callback

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

Re: [PATCH] kprobes: Correct a type error in function kprobes_module_callback

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.

[PATCH] kprobes: Correct a type error in function kprobes_module_callback

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

[PATCH] RCU: Adjust comments for force_qs_rnp

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. Signed-off-by: Zhou

Re: [PATCH] srcu: remove never used variable

Thanks Paul's encouragement, I will keep studying SRCU code. On Fri, Feb 23, 2018 at 9:20 AM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Fri, Feb 23, 2018 at 09:04:05AM +0800, Zhouyi Zhou wrote: >> Thanks Paul for reviewing > > And thank you for your interest

Re: [PATCH] srcu: remove never used variable

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

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

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

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

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

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

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 <zhouzho...@gmail.com> wrote: > Hi, > I will try to reestablish the environment, and

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

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

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

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 <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Tue, Nov 28, 201

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

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

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

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 <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 10:17 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> H

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

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_B

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

wrote: > On Tue, Nov 28, 2017 at 9:33 AM, Zhouyi Zhou <zhouzho...@gmail.com> 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 >&g

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

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. >> &g

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

try Vyukov <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 9:00 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> Thanks for reviewing >>My machine has 128G of RAM, and runs many KVM virtual machines. >> libvirtd always >> report "internal error:

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

try 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: received hangup / error event on socket" under >

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

v 28, 2017 at 3:45 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Tue, Nov 28, 2017 at 5:05 AM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> When there are huge amount of quarantined cache allocates in system, >> number of entries in global_quarantine[i] will be g

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

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

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

. On Tue, Nov 28, 2017 at 12:04 PM, <zhouzho...@gmail.com> wrote: > From: Zhouyi Zhou <zhouzho...@gmail.com> > > 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 <zho

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

. 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

[PATCH v2 2/2] docs: disable KASLR when debugging kernel

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 <zhouzho...@gmail.

[PATCH v2 2/2] docs: disable KASLR when debugging kernel

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

Re: [PATCH 2/2] docs: disable KASLR when debugging kernel

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 <kbing...@kernel.org> wrote: > Hi Zhouyi > > Thankyou for the patch, > > On 07/07/17 08:14, Zhouyi Zhou wrote: >> commit

Re: [PATCH 2/2] docs: disable KASLR when debugging kernel

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

[PATCH 2/2] docs: disable KASLR when debugging kernel

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

[PATCH 2/2] docs: disable KASLR when debugging kernel

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/

[PATCH 2/1] docs: disable KASLR when debugging kernel

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

[PATCH 2/1] docs: disable KASLR when debugging kernel

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

Re: [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

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 <jeffrey.t.kirs...@intel.com> wrote: > On Wed, 2016-12-07 at 15:43 +0800, Zhouyi Zhou wrote: >> Signed-off-by: Zhouyi Zhou <yizhouz...@ict.

Re: [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

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

Re: [PATCH 1/1] scsi: fcoe: return value of skb_linearize should be handled

Thanks Johannes for reviewing, your code is indeeded more elegant On Wed, Dec 7, 2016 at 4:28 PM, Johannes Thumshirn <jthumsh...@suse.de> wrote: > Hi Zhouyi, > On Wed, Dec 07, 2016 at 04:00:00PM +0800, Zhouyi Zhou wrote: >> Return value of skb_linearize should be handled

Re: [PATCH 1/1] scsi: fcoe: return value of skb_linearize should be handled

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

[PATCH 1/1] tipc: return value of skb_linearize should be handled

return value of skb_linearize should be handled Signed-off-by: Zhouyi Zhou <yizhouz...@ict.ac.cn> Reviewed-by: Cong Wang <xiyou.wangc...@gmail.com> Reviewed-by: Yuval Shaia <yuval.sh...@oracle.com> Reviewed-by: Eric Dumazet <eric.duma...@gmail.com> --- net/tipc/link.c

[PATCH 1/1] tipc: return value of skb_linearize should be handled

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

[PATCH 1/1] scsi: fcoe: return value of skb_linearize should be handled

Return value of skb_linearize should be handled. Signed-off-by: Zhouyi Zhou <yizhouz...@ict.ac.cn> Reviewed-by: Yuval Shaia <yuval.sh...@oracle.com> --- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 6 -- drivers/scsi/fcoe/fcoe.c | 5 - 2 files changed, 8 insertions(+),

[PATCH 1/1] scsi: fcoe: return value of skb_linearize should be handled

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

[PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

Signed-off-by: Zhouyi Zhou <yizhouz...@ict.ac.cn> Reviewed-by: Cong Wang <xiyou.wangc...@gmail.com> Reviewed-by: Yuval Shaia <yuval.sh...@oracle.com> Reviewed-by: Eric Dumazet <eric.duma...@gmail.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 6 +- drivers/

[PATCH 1/1] ixgbe: fcoe: 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 --- 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

[PATCH 1/1] infiniband: nes: return value of skb_linearize should be handled

Return value of skb_linearize should be handled in function nes_netdev_start_xmit. Compiled in x86_64 Signed-off-by: Zhouyi Zhou <yizhouz...@ict.ac.cn> Reviewed-by: Yuval Shaia <yuval.sh...@oracle.com> Reviewed-by: Eric Dumazet <eric.duma...@gmail.com> --- drivers/infiniban

[PATCH 1/1] infiniband: nes: return value of skb_linearize should be handled

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

Re: [PATCH] net: return value of skb_linearize should be handled in Linux kernel

On Wed, Dec 7, 2016 at 1:02 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Dec 5, 2016 at 11:10 PM, Zhouyi Zhou <zhouzho...@gmail.com> wrote: >> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c >> b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.

Re: [PATCH] net: return value of skb_linearize should be handled in Linux kernel

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

[PATCH] net: return value of skb_linearize should be handled in Linux kernel

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 <zhouzho...@gmail.com> --- drivers/infiniband/hw/nes/nes

[PATCH] net: return value of skb_linearize should be handled in Linux kernel

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

patch mail rejected by vger.kernel.org

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

patch mail rejected by vger.kernel.org

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

Re: Re: [PATCH] relay: fix potential memory leak

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

Re: Re: [PATCH] relay: fix potential memory leak

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

[PATCH] relay: fix potential memory leak

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 <zhouzho...@gmail.com> --- kernel/relay.c | 8 1 file changed, 8 inse

[PATCH] relay: fix potential memory leak

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

Re: Re: [PATCH V7] netfilter: h323: avoid potential attack

Thanks Pablo for reviewing > From: "Pablo Neira Ayuso" <pa...@netfilter.org> > Sent Time: Saturday, March 12, 2016 > To: "Zhouyi Zhou" <zhouzho...@gmail.com> > On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote: > > I think hackers cho

Re: Re: [PATCH V7] netfilter: h323: avoid potential attack

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

[PATCH V7] netfilter: h323: avoid potential attack

ons 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 <yizhouz...@ict.ac.cn> --- include/linux/netfilter/nf_conntrack_h323.h | 17 +- net/ipv4/netfilter/nf_nat_h323.c| 33 ++- net/

[PATCH V7] netfilter: h323: avoid potential attack

ons 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

[PATCH V6] netfilter: h323: avoid potential attack

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

[PATCH V6] netfilter: h323: avoid potential attack

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 <yizhouz...@ict.ac.cn>

[PATCH V5] netfilter: h323: avoid potential attack

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 |

[PATCH V4] netfilter: h323: avoid potential attack

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

[PATCH V4] netfilter: h323: avoid potential attack

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 <yizhouz...@ict.ac.cn> --- net/netfilter/nf_conntrack_h323_main.c | 31 +++ 1 file changed, 31 insertions(+) diff --

[PATCH V5] netfilter: h323: avoid potential attack

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 <yizhouz...@ict.ac.cn> --- net/netfilter/nf_conntrack_h3

[PATCH V3] netfilter: h323: avoid potential attack

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

Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

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

Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

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

[PATCH V2] netfilter: h323: avoid potential attack

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

[PATCH V2] netfilter: h323: avoid potential attack

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 <yizhouz...@ict.ac.cn>

Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

Thanks Eric for replying > -Original Messages- > From: "Eric Dumazet" <eric.duma...@gmail.com> > Sent Time: Thursday, January 28, 2016 > To: "Zhouyi Zhou" <zhouzho...@gmail.com> > Cc: pa...@netfilter.org, ka...@trash.net, kad...@blackhol

[PATCH V3] netfilter: h323: avoid potential attack

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 <yizhouz...@ict.ac.cn> Signed-off-by: Eric Dumazet <eric.duma...@gmail.com> Reviewed-by: Sergei Shtylyov <sergei.shtyl...@cogentembedd

Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

gt; > Sent Time: Thursday, January 28, 2016 > To: "Zhouyi Zhou" <zhouzho...@gmail.com> > 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...

[PATCH 1/1] netfilter: h323: avoid potential attack

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 |

[PATCH 1/1] netfilter: h323: avoid potential attack

From: Zhouyi Zhou <yizhouz...@ict.ac.cn> 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 <zhouzho...@gmail.c

[RFC] ACPICA: save a function call

to 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/psobject.c b

[RFC] ACPICA: save a function call

to 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 yizhouz...@ict.ac.cn --- drivers/acpi/acpica/psobject.c |8 1 file changed, 8 deletions(-) diff --git a/drivers/acpi/acpica

[PATCH] ACPI: Fix indent for variable declaration

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

[PATCH] ACPI: Fix indent for variable declaration

In function acpi_ns_one_complete_parse, the variable declaration aml_length is not correctly indented. Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn --- drivers/acpi/acpica/nsparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/nsparse.c b/drivers

[PATCH V2 1/1] netfilter/jump_label: HAVE_JUMP_LABEL instead of CONFIG_JUMP_LABEL

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

Re: [PATCH 1/1] netfilter/jump_label: use HAVE_JUMP_LABEL?

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

Re: [PATCH 1/1] netfilter/jump_label: use HAVE_JUMP_LABEL?

Thanks Florian for reviewing -Original Messages- From: Florian Westphal f...@strlen.de Zhouyi Zhou zhouzho...@gmail.com wrote: 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

[PATCH V2 1/1] netfilter/jump_label: HAVE_JUMP_LABEL instead of CONFIG_JUMP_LABEL

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 yizhouz...@ict.ac.cn Reviewed-by: Florian Westphal f...@strlen.de --- include/linux/netfilter.h |5 +++-- net/netfilter

Re: [PATCH 1/1] jump_label: tidy jump_label_ratelimit.h

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

[PATCH 1/1] netfilter/jump_label: use HAVE_JUMP_LABEL?

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 insertions(+), 5

[PATCH 1/1] powerpc/jump_label: use HAVE_JUMP_LABEL?

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

[PATCH 1/1] jump_label: tidy jump_label_ratelimit.h

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

[PATCH 1/1] jump_label: tidy jump_label_ratelimit.h

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 yizhouz

[PATCH 1/1] powerpc/jump_label: use HAVE_JUMP_LABEL?

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 yizhouz...@ict.ac.cn --- arch/powerpc/platforms/powernv/opal-tracepoints.c |2 +- arch/powerpc/platforms/pseries/lpar.c

[PATCH 1/1] netfilter/jump_label: use HAVE_JUMP_LABEL?

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 yizhouz...@ict.ac.cn --- include/linux/netfilter.h |5 +++-- net/netfilter/core.c |6 +++--- 2 files changed, 6

Re: [PATCH 1/1] jump_label: tidy jump_label_ratelimit.h

Thanks Jason for reviewing it -Original Messages- From: Jason Baron jba...@akamai.com Sent Time: Thursday, August 21, 2014 To: Zhouyi Zhou zhouzho...@gmail.com Cc: drjo...@redhat.com, konrad.w...@oracle.com, raghavendra...@linux.vnet.ibm.com, mi...@kernel.org, da...@davemloft.net

Re: Re: [PATCH net-next] pktgen: add ttl option for pktgen

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

[PATCH net-next] pktgen: add ttl option for pktgen

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 Zhou

[PATCH net-next] pktgen: add ttl option for pktgen

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

Re: Re: [PATCH net-next] pktgen: add ttl option for pktgen

Thanks for reviewing. I did miss it. -Original Messages- From: Dmitry Popov ixaph...@qrator.net Sent Time: Wednesday, July 30, 2014 To: Zhouyi Zhou zhouzho...@gmail.com Cc: rdun...@infradead.org, da...@davemloft.net, mini...@googlemail.com, bro...@redhat.com, steffen.klass

[tip:perf/core] perf/x86/amd: Try to fix some mem allocation failure handling

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

  1   2   >