On Mon, May 04, 2020 at 11:34:31AM -0700, Joe Perches wrote:
> On Mon, 2020-05-04 at 16:20 +0800, Wang YanQing wrote:
> > According to submitting-patches.rst, 'Fixes:' tag has a little
> > stricter condition about the one line summary than normal git
> > commit descrip
On Mon, May 04, 2020 at 11:45:02AM +0200, Markus Elfring wrote:
>
> > 4: Add support to check and emit sensible diagnostics
> > info for description which spans across more than
> > two lines.
>
> My software concerns are growing also for the preferred dependency management.
>
format check.
Based on original patch by Joe Perches
Link:
https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.ca...@perches.com/
Signed-off-by: Wang YanQing
---
v6:
1: Fix indentation issue.
2: Fix a typo issue, reported by Markus Elfring.
3: Reword some diagnostics info.
4: Add
nes, see above examples.
This patch adds support to recognize commit description which spans across
three lines, then it will not emit error message for such situation.
Signed-off-by: Wang YanQing
---
Hi! Joe
I have tested with below command:
git log -1 --format=%H -i --grep=" com
On Sun, May 03, 2020 at 03:51:39PM +0200, Markus Elfring wrote:
>
>
> …
> > + $diagnostics .= "The title is too
> > abbreviated, at least half of orignial commit title is necessary.\n";
>
> Will the word “original” be more appropriate here?
> (Why did you not
format check.
Based on original patch by Joe Perches
Link:
https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.ca...@perches.com/
Signed-off-by: Wang YanQing
---
Hi! Joe and all.
This is the v5 version, and I have tested it with below command:
$ git log -1 --no-merges --grep
,
and emit diagnostics info when the title acrosses more than three lines.
Signed-off-by: Wang YanQing
---
Hi! Joe
This is the third patch based on previous two patches.
Thanks.
scripts/checkpatch.pl | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
On Sat, May 02, 2020 at 09:40:24PM +0200, Markus Elfring wrote:
>
>
> > + $diagnostics .= "Missing a pair of parentheses
> > '()' or a pair of double quotation marks (\"\").\n";
>
> Can such a message trigger any more thoughts and development ideas?
No, I don't think
to GIT_COMMIT_ID, and uses ERROR instead of WARN, because unknown commit
id is total useless to track change history in changelog, it deserves the
ERROR.
Signed-off-by: Wang YanQing
---
v2:
1: Fix annonying "Invalid commit id" reports for non commit id number string.
2: Fix indent
to GIT_COMMIT_ID, and uses ERROR instead of WARN, because unknown commit
id is total useless to track change history in changelog, it deserves the
ERROR.
Signed-off-by: Wang YanQing
---
After this patch, in another patch 'checkpatch: add support to check 'Fixes:'
tag format',
I will delete
Commit e33e2241e272 ("Revert "cfg80211: Use 5MHz bandwidth by default
when checking usable channels"")
Note: this patch also adds diagnostics info support for normal git commit
description format check.
Based on original patch by Joe Perches
Link:
https://l
On Fri, May 01, 2020 at 08:57:42AM -0700, Joe Perches wrote:
> On Fri, 2020-05-01 at 23:40 +0800, Wang YanQing wrote:
> > According to submitting-patches.rst, 'Fixes:' tag has a little
> > stricter condition about the one line summary than normal git
> > commit descrip
orts double quotation mark in
title line, for example:
Commit e33e2241e272 ("Revert "cfg80211: Use 5MHz bandwidth by default
when checking usable channels"")
Based on original patch by Joe Perches
Link:
https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b8610
orts double quotation mark in
title line, for example:
Commit e33e2241e272 ("Revert "cfg80211: Use 5MHz bandwidth by default
when checking usable channels"")
Based on original patch by Joe Perches
Link:
https://lore.kernel.org/lkml/40bfc40958fca6e2cc9
On Wed, Apr 29, 2020 at 07:40:21PM +0200, Markus Elfring wrote:
> > “...
> > Do not split the tag across multiple
> > lines, tags are exempt from the "wrap at 75 columns" rule in order to
> > simplify
> > parsing scripts
> > ...”
>
> Why do you not like the reformatting of the quotation so far
>
l.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.ca...@perches.com/
Signed-off-by: Wang YanQing
---
scripts/checkpatch.pl | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 23a001a..879dcf4 100755
--- a/scripts/checkpatc
On Tue, Apr 28, 2020 at 12:52:59PM +0200, Markus Elfring wrote:
> > And there is no 'Fixes:' tag format checker in checkpatch
>
> I have taken another look at corresponding implementation details.
> Will programming challenges get any more attention?
>
>
> > to check the commit id length too,
>
On Tue, Apr 28, 2020 at 08:21:37AM +0200, Markus Elfring wrote:
> > ...
> > Do not split the tag across multiple
> > lines, tags are exempt from the "wrap at 75 columns" rule in order to
> > simplify
> > parsing scripts
> > ...
>
> I suggest to reformat the quotation.
>
> “…
> Do not split the
On Thu, Apr 18, 2019 at 05:09:53AM +, Yonghong Song wrote:
>
>
> On 4/17/19 10:48 AM, Wang YanQing wrote:
> > The older glibc (for example, 2.23) doesn't handle __UAPI_DEF_*
> > in libc-compat.h properly, and it bring below compile errors:
>
> I have an even
by moving to before the
.
Signed-off-by: Wang YanQing
---
Changes
v1-v2:
1:Rewrite the changelog.
tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c| 2 +-
tools/testing/selftests/bpf/progs/test_tcpnotify_kern.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/too
On Thu, Apr 18, 2019 at 05:09:53AM +, Yonghong Song wrote:
>
>
> On 4/17/19 10:48 AM, Wang YanQing wrote:
> > The older glibc (for example, 2.23) doesn't handle __UAPI_DEF_*
> > in libc-compat.h properly, and it bring below compile errors:
>
> I have an even
33:26: note: expanded from macro 'IPPROTO_FRAGMENT'
"
The same compile errors are reported for test_tcpbpf_kern.c too.
This patch fixes the compile errors by moving to before the
.
Signed-off-by: Wang YanQing
---
tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c| 2 +-
tools/testing
it.
Fixes: 24dea04767e6 ("bpf, x32: remove ld_abs/ld_ind")
Signed-off-by: Wang YanQing
---
arch/x86/net/bpf_jit_comp32.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp32.c b/arch/x86/net/bpf_jit_comp32.c
index 5579987..8f6cc71 10064
it.
Fixes: 24dea04767e6 ("bpf, x32: remove ld_abs/ld_ind")
Signed-off-by: Wang YanQing
---
arch/x86/net/bpf_jit_comp32.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp32.c b/arch/x86/net/bpf_jit_comp32.c
index 5579987..8f6cc71 10064
imm24 is signed, so the right range is:
[-(1<<(24 - 1)), (1<<(24 - 1)) - 1]
Note:this patch also fix a typo.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes
v1-v2:
1:Rewrite the patch, I make a mistake, the v1 is wrong totally,
reported by Russell King.
imm24 is signed, so the right range is:
[-(1<<(24 - 1)), (1<<(24 - 1)) - 1]
Note:this patch also fix a typo.
Signed-off-by: Wang YanQing
---
Changes
v1-v2:
1:Rewrite the patch, I make a mistake, the v1 is wrong totally,
reported by Russell King.
I use the fix suggested by
-by: Wang YanQing <udkni...@gmail.com>
---
Changes v1-v2:
1:Rewords the changelog.
arch/arm/net/bpf_jit_32.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index b5030e1..caccc78 100644
--- a/arch/arm/net/bpf_
-by: Wang YanQing
---
Changes v1-v2:
1:Rewords the changelog.
arch/arm/net/bpf_jit_32.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index b5030e1..caccc78 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm
On Thu, May 10, 2018 at 08:56:57AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote:
> > imm24 is signed, so the right range is:
> > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
>
> 2 << (24 - 1) is the same as
On Thu, May 10, 2018 at 08:56:57AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote:
> > imm24 is signed, so the right range is:
> > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
>
> 2 << (24 - 1) is the same as
imm24 is signed, so the right range is:
[-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
Note:this patch also fix a typo.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
arch/arm/net/bpf_jit_32.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/ar
imm24 is signed, so the right range is:
[-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
Note:this patch also fix a typo.
Signed-off-by: Wang YanQing
---
arch/arm/net/bpf_jit_32.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/
The reasonable names for emit_a32_lsr_r64|emit_a32_lsr_i64 are
emit_a32_rsh_r64|emit_a32_rsh_i64.
This patch also correct a wrong comment.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
arch/arm/net/bpf_jit_32.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
The reasonable names for emit_a32_lsr_r64|emit_a32_lsr_i64 are
emit_a32_rsh_r64|emit_a32_rsh_i64.
This patch also correct a wrong comment.
Signed-off-by: Wang YanQing
---
arch/arm/net/bpf_jit_32.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/net
For me, as a reader whose mother language isn't English, the
old words bring a little difficulty to catch the meaning, this
patch rewords the subsection in a more clarificatory way.
This patch also add blank lines as separator at two places
to improve readability.
Signed-off-by: Wang YanQing
For me, as a reader whose mother language isn't English, the
old words bring a little difficulty to catch the meaning, this
patch rewords the subsection in a more clarificatory way.
This patch also add blank lines as separator at two places
to improve readability.
Signed-off-by: Wang YanQing
:
"
Caizhiyong <caizhiy...@hisilicon.com> said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes
v4-v5:
1:De
:
"
Caizhiyong said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"
Signed-off-by: Wang YanQing
---
Changes
v4-v5:
1:Delete unnecessary blank line at begin and end of logs.
:
"
Caizhiyong <caizhiy...@hisilicon.com> said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes
v3-v
:
"
Caizhiyong said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"
Signed-off-by: Wang YanQing
---
Changes
v3-v4:
1:Fix grammar typo, reported by Randy Dunlap.
2:Delete unnece
On Sat, Apr 28, 2018 at 01:29:17PM +0800, Wang YanQing wrote:
> On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> > On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> &
On Sat, Apr 28, 2018 at 01:29:17PM +0800, Wang YanQing wrote:
> On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> > On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> &
I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.
This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will log a warning.
Signed-off-by: Wang YanQing <ud
I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.
This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will log a warning.
Signed-off-by: Wang YanQing
---
Changes
:
"
Caizhiyong <caizhiy...@hisilicon.com> said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes
v1-v2:
:
"
Caizhiyong said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"
Signed-off-by: Wang YanQing
---
Changes
v1-v2:
1:Don't treat overlaps partition as a error, but log a warnin
I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.
This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will return error and log
a error message.
Signed-off-by: Wang
I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.
This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will return error and log
a error message.
Signed-off-by: Wang
Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes v5-v6:
1:Add do {} while (0) to RETPOLINE_RAX_BPF_JIT for
consistence reason.
2:Clean up non-standard comments, reported by Daniel Borkmann.
3:Fix a memory leak issue, r
Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing
---
Changes v5-v6:
1:Add do {} while (0) to RETPOLINE_RAX_BPF_JIT for
consistence reason.
2:Clean up non-standard comments, reported by Daniel Borkmann.
3:Fix a memory leak issue, repoted by Daniel Borkmann
Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes v4-v5:
1:Delete is_on_stack, BPF_REG_AX is the only one
on real hardware registers, so just check with
it.
2:Apply commit 1612a981b766 ("bpf, x64: fix JIT emission
Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing
---
Changes v4-v5:
1:Delete is_on_stack, BPF_REG_AX is the only one
on real hardware registers, so just check with
it.
2:Apply commit 1612a981b766 ("bpf, x64: fix JIT emission
for dead code"),
On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in
> >> test_verif
On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in
> >> test_verif
Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes v3-v4:
1:Fix changelog in commit.
I install llvm-6.0, then test_progs willn't report errors.
I submit another patch:
"bpf: fix misaligned access for BPF_PROG_TYPE
Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing
---
Changes v3-v4:
1:Fix changelog in commit.
I install llvm-6.0, then test_progs willn't report errors.
I submit another patch:
"bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program
y necessary for x86_32, it will fix the
same problem for other platforms too, if their size of bpf_user_pt_regs_t
can't divide exactly into 8.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Hi all!
After mainline accept this patch, then we need to submit a sync patch
to update
y necessary for x86_32, it will fix the
same problem for other platforms too, if their size of bpf_user_pt_regs_t
can't divide exactly into 8.
Signed-off-by: Wang YanQing
---
Hi all!
After mainline accept this patch, then we need to submit a sync patch
to update the tools/include/uapi/linux/bpf_
On Wed, Apr 25, 2018 at 02:11:16AM +0200, Daniel Borkmann wrote:
> On 04/19/2018 05:54 PM, Wang YanQing wrote:
> > Testing results on i5-5200U:
> >
> > 1) test_bpf: Summary: 349 PASSED, 0 FAILED, [319/341 JIT'ed]
> > 2) test_progs: Summary: 81 PASSED, 2 FAILED.
>
On Wed, Apr 25, 2018 at 02:11:16AM +0200, Daniel Borkmann wrote:
> On 04/19/2018 05:54 PM, Wang YanQing wrote:
> > Testing results on i5-5200U:
> >
> > 1) test_bpf: Summary: 349 PASSED, 0 FAILED, [319/341 JIT'ed]
> > 2) test_progs: Summary: 81 PASSED, 2 FAILED.
>
ASS:ipv6:5092/100=50
test_xdp:PASS:ipv4:131902/100=1319
test_xdp:PASS:ipv6:77932/100=779
test_l4lb:PASS:ipv4:38924/100=389
test_l4lb:PASS:ipv6:57520/100=575
The numbers show we get 30%~50% improvement.
See Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing <udkni...@gma
ASS:ipv6:5092/100=50
test_xdp:PASS:ipv4:131902/100=1319
test_xdp:PASS:ipv6:77932/100=779
test_l4lb:PASS:ipv4:38924/100=389
test_l4lb:PASS:ipv6:57520/100=575
The numbers show we get 30%~50% improvement.
See Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing
---
Ch
On Wed, Apr 25, 2018 at 02:11:16AM +0200, Daniel Borkmann wrote:
> On 04/19/2018 05:54 PM, Wang YanQing wrote:
> > The JIT compiler emits ia32 bit instructions. Currently, It supports
> > eBPF only. Classic BPF is supported because of the conversion by BPF core.
> >
> &
On Wed, Apr 25, 2018 at 02:11:16AM +0200, Daniel Borkmann wrote:
> On 04/19/2018 05:54 PM, Wang YanQing wrote:
> > The JIT compiler emits ia32 bit instructions. Currently, It supports
> > eBPF only. Classic BPF is supported because of the conversion by BPF core.
> >
> &
speedup
jit_harden, then we need to move BPF_REG_AX to *real* register instead of stack
emulation, but when we do it, we need to face all the pain I describe above. We
can do it in next step.
See Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing <udkni...@gm
speedup
jit_harden, then we need to move BPF_REG_AX to *real* register instead of stack
emulation, but when we do it, we need to face all the pain I describe above. We
can do it in next step.
See Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing
--
On Wed, Apr 18, 2018 at 05:31:18PM +0800, Wang YanQing wrote:
> The JIT compiler emits ia32 bit instructions. Currently, It supports
> eBPF only. Classic BPF is supported because of the conversion by BPF core.
>
> Almost all instructions from eBPF ISA supported except the following:
On Wed, Apr 18, 2018 at 05:31:18PM +0800, Wang YanQing wrote:
> The JIT compiler emits ia32 bit instructions. Currently, It supports
> eBPF only. Classic BPF is supported because of the conversion by BPF core.
>
> Almost all instructions from eBPF ISA supported except the following:
ll the pain I describe above. We
can do it in next step.
See Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
arch/x86/Kconfig |2 +-
arch/x86/include/asm/nospec-branch.h | 26 +-
arch/x86/net/Makefile
ll the pain I describe above. We
can do it in next step.
See Documentation/networking/filter.txt for more information.
Signed-off-by: Wang YanQing
---
arch/x86/Kconfig |2 +-
arch/x86/include/asm/nospec-branch.h | 26 +-
arch/x86/net/Makefile| 10
Commit-ID: ea85ab24c502720d2eb3dec30bedb6df06d4900b
Gitweb: https://git.kernel.org/tip/ea85ab24c502720d2eb3dec30bedb6df06d4900b
Author: Wang YanQing <udkni...@gmail.com>
AuthorDate: Thu, 8 Mar 2018 11:28:50 +0800
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
Commit
Commit-ID: ea85ab24c502720d2eb3dec30bedb6df06d4900b
Gitweb: https://git.kernel.org/tip/ea85ab24c502720d2eb3dec30bedb6df06d4900b
Author: Wang YanQing
AuthorDate: Thu, 8 Mar 2018 11:28:50 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Mar 2018 11:30:51 -0300
perf report
(aa_alloc_task_context+0x27) call_site=81370b87 ptr=0x428a3060
bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
0.01% (__tty_buffer_request_room+0x88) call_site=814e5828
ptr=0x99bb000 bytes_req=3616 bytes_alloc=4096 gfp_flags=GFP_ATOMIC
Signed-off-by: Wang YanQing <
(aa_alloc_task_context+0x27) call_site=81370b87 ptr=0x428a3060
bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
0.01% (__tty_buffer_request_room+0x88) call_site=814e5828
ptr=0x99bb000 bytes_req=3616 bytes_alloc=4096 gfp_flags=GFP_ATOMIC
Signed-off-by: Wang YanQing
Acked-by
(aa_alloc_task_context+0x27) call_site=81370b87 ptr=0x428a3060
bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
0.01% (__tty_buffer_request_room+0x88) call_site=814e5828
ptr=0x99bb000 bytes_req=3616 bytes_alloc=4096 gfp_flags=GFP_ATOMIC
Signed-off-by: Wang YanQing <
(aa_alloc_task_context+0x27) call_site=81370b87 ptr=0x428a3060
bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
0.01% (__tty_buffer_request_room+0x88) call_site=814e5828
ptr=0x99bb000 bytes_req=3616 bytes_alloc=4096 gfp_flags=GFP_ATOMIC
Signed-off-by: Wang YanQing
Acked-by
On Thu, Feb 08, 2018 at 01:20:31PM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > So that beautifiers wanting to resolve kernel function addresses to
> > names can do its work, and when we use "perf report" for output of
&
On Thu, Feb 08, 2018 at 01:20:31PM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > So that beautifiers wanting to resolve kernel function addresses to
> > names can do its work, and when we use "perf report" for output of
&
If we then OR this with 0x40, then the value of 6th bit (0th is first bit)
become known, so the right mask is 0xbf instead of 0xcf.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Documentation/networking/filter.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
If we then OR this with 0x40, then the value of 6th bit (0th is first bit)
become known, so the right mask is 0xbf instead of 0xcf.
Signed-off-by: Wang YanQing
---
Documentation/networking/filter.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking
Commit-ID: 4c0d8d27954d9efb2a02ec9fc16f39b02f248bb7
Gitweb: https://git.kernel.org/tip/4c0d8d27954d9efb2a02ec9fc16f39b02f248bb7
Author: Wang YanQing <udkni...@gmail.com>
AuthorDate: Mon, 15 Jan 2018 13:04:48 +0800
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
CommitD
Commit-ID: 4c0d8d27954d9efb2a02ec9fc16f39b02f248bb7
Gitweb: https://git.kernel.org/tip/4c0d8d27954d9efb2a02ec9fc16f39b02f248bb7
Author: Wang YanQing
AuthorDate: Mon, 15 Jan 2018 13:04:48 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 23 Jan 2018 09:49:28 -0300
perf symbols
On Fri, Jan 19, 2018 at 07:57:59PM +0100, Jiri Olsa wrote:
> On Thu, Jan 18, 2018 at 10:22:30PM +0800, Wang YanQing wrote:
> > On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote:
> > > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote:
> > > > On M
On Fri, Jan 19, 2018 at 07:57:59PM +0100, Jiri Olsa wrote:
> On Thu, Jan 18, 2018 at 10:22:30PM +0800, Wang YanQing wrote:
> > On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote:
> > > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote:
> > > > On M
On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote:
> On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote:
> > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote:
> > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > > &g
On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote:
> On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote:
> > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote:
> > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > > &g
On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > So that beautifiers wanting to resolve kernel function addresses to
> > names can do its work, and when we use "perf report" for output of
&
On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > So that beautifiers wanting to resolve kernel function addresses to
> > names can do its work, and when we use "perf report" for output of
&
On Mon, Jan 15, 2018 at 10:45:06AM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 01:04:48PM +0800, Wang YanQing wrote:
> > I meet strange behavior with below commands on my gentoo box:
> > 1:perf kmem record
> > 2:CTRL-C to stop 1
> > 3:perf report
> > 4:"
On Mon, Jan 15, 2018 at 10:45:06AM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 01:04:48PM +0800, Wang YanQing wrote:
> > I meet strange behavior with below commands on my gentoo box:
> > 1:perf kmem record
> > 2:CTRL-C to stop 1
> > 3:perf report
> > 4:"
en "script_browse" uses popen to run "perf script" which
run out of open files. The gentoo box has a small default value for
"max open files", 1024. Yes, "ulimit -n " with a bigger number could
fix it, but I think that using O_CLOEXEC in do_open is a better way.
en "script_browse" uses popen to run "perf script" which
run out of open files. The gentoo box has a small default value for
"max open files", 1024. Yes, "ulimit -n " with a bigger number could
fix it, but I think that using O_CLOEXEC in do_open is a better way
After commit 4263cece22e3da94f16fbbcf71ce3807946d3ef3
("perf tools: Stop reading the kallsyms data from perf.data"),
there is no users of pevent_register_function in tree, so we
could just delete it.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
tools/lib/traceevent/eve
After commit 4263cece22e3da94f16fbbcf71ce3807946d3ef3
("perf tools: Stop reading the kallsyms data from perf.data"),
there is no users of pevent_register_function in tree, so we
could just delete it.
Signed-off-by: Wang YanQing
---
tools/lib/traceevent/event-par
So that beautifiers wanting to resolve kernel function addresses to
names can do its work, and when we use "perf report" for output of
"perf kmem record", we will get kernel symbol output.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
tools/perf/builtin-repo
So that beautifiers wanting to resolve kernel function addresses to
names can do its work, and when we use "perf report" for output of
"perf kmem record", we will get kernel symbol output.
Signed-off-by: Wang YanQing
---
tools/perf/builtin-report.c | 9 +
1 file c
When hda_codec_driver_probe meet error and return failure, we need
to free resource with patch_ops.free, or we will get resource leak.
Signed-off-by: Wang YanQing <udkni...@gmail.com>
---
Changes v1-v2:
1: Fix calling patch_ops.free after module_put, reported by Takashi Iwai.
Hi! Takash
When hda_codec_driver_probe meet error and return failure, we need
to free resource with patch_ops.free, or we will get resource leak.
Signed-off-by: Wang YanQing
---
Changes v1-v2:
1: Fix calling patch_ops.free after module_put, reported by Takashi Iwai.
Hi! Takashi Iwai
Because the only
On Sun, Sep 03, 2017 at 11:27:31PM +0800, Wang YanQing wrote:
> When patch_ops.init, patch_ops.build_pcms and patch_ops.build_controls
> return failure, we need to free resource with patch_ops.free, or we will
> get resource leak.
>
> Signed-off-by: Wang YanQing <
On Sun, Sep 03, 2017 at 11:27:31PM +0800, Wang YanQing wrote:
> When patch_ops.init, patch_ops.build_pcms and patch_ops.build_controls
> return failure, we need to free resource with patch_ops.free, or we will
> get resource leak.
>
> Signed-off-by: Wang YanQing
> --
1 - 100 of 529 matches
Mail list logo
