Re: [PATCH v3] tracepoint: Do not fail unregistering a probe due to memory allocation

artin KaFai Lau > Cc: Song Liu > Cc: Yonghong Song > Cc: Andrii Nakryiko > Cc: John Fastabend > Cc: KP Singh > Cc: netdev > Cc: bpf > Cc: Kees Cook > Cc: Florian Weimer > Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints") > Reported-by: syzbot+83a

Re: [PATCH] bpf: don't fail kmalloc while releasing raw_tp

On Tue, Nov 17, 2020 at 06:05:51PM -0500, Mathieu Desnoyers wrote: > - On Nov 16, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote: > > > On Mon, 16 Nov 2020 16:34:41 -0500 (EST) > > Mathieu Desnoyers wrote: > > [...] > > >> I think you'll want a WRITE_ONCE(old[i].func, tp_stub_func)

[PATCH] bpf: don't fail kmalloc while releasing raw_tp

...@syzkaller.appspotmail.com Signed-off-by: Matt Mullins --- I previously referenced a "pretty ugly" patch. This is not that one, because I don't think there's any way I can make the caller of ->release() actually handle errors like ENOMEM. It also looks like most of the other ways tracepoint_probe_unregis

Re: KASAN: vmalloc-out-of-bounds Read in bpf_trace_run3

compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10f4b03250 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1371a47c50 > > > > The issue was bisected to: > > > > commit 9

[tip:x86/urgent] x86/entry/32: Pass cr2 to do_async_page_fault()

Commit-ID: b8f70953c1251d8b16276995816a95639f598e70 Gitweb: https://git.kernel.org/tip/b8f70953c1251d8b16276995816a95639f598e70 Author: Matt Mullins AuthorDate: Tue, 23 Jul 2019 21:20:58 -0700 Committer: Thomas Gleixner CommitDate: Wed, 24 Jul 2019 12:17:39 +0200 x86/entry/32: Pass

[PATCH] x86/entry/32: pass cr2 to do_async_page_fault

page_fault and async_page_fault. For a 32-bit KVM guest, this fixes: [1.148669][T1] Run /sbin/init as init process [1.153328][T1] Starting init: /sbin/init exists but couldn't execute it (error -14) Fixes: a0d14b8909de ("x86/mm, tracing: Fix CR2 corruption") Signed-

Re: [PATCH] bpf: hide do_bpf_send_signal when unused

On Mon, 2019-06-17 at 19:09 -0400, Steven Rostedt wrote: > On Mon, 17 Jun 2019 08:26:29 -0700 > Alexei Starovoitov wrote: > > > On Mon, Jun 17, 2019 at 5:59 AM Arnd Bergmann wrote: > > > > > > When CONFIG_MODULES is disabled, this function is never called: > > > > > >

Re: [PATCH bpf v2] bpf: fix nested bpf tracepoints with per-cpu data

On Fri, 2019-06-14 at 16:50 +0200, Daniel Borkmann wrote: > On 06/14/2019 02:51 AM, Matt Mullins wrote: > > On Fri, 2019-06-14 at 00:47 +0200, Daniel Borkmann wrote: > > > On 06/12/2019 07:00 AM, Andrii Nakryiko wrote: > > > > On Tue, Jun 11, 2019

Re: [PATCH bpf v2] bpf: fix nested bpf tracepoints with per-cpu data

On Fri, 2019-06-14 at 00:47 +0200, Daniel Borkmann wrote: > On 06/12/2019 07:00 AM, Andrii Nakryiko wrote: > > On Tue, Jun 11, 2019 at 8:48 PM Matt Mullins wrote: > > > > > > BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as > > > t

[tip:x86/urgent] x86/kgdb: Return 0 from kgdb_arch_set_breakpoint()

Commit-ID: 71ab8323cc357c68985a2d6fc6cfc22b1dbbc1c3 Gitweb: https://git.kernel.org/tip/71ab8323cc357c68985a2d6fc6cfc22b1dbbc1c3 Author: Matt Mullins AuthorDate: Fri, 31 May 2019 12:47:54 -0700 Committer: Borislav Petkov CommitDate: Wed, 12 Jun 2019 18:52:44 +0200 x86/kgdb: Return 0

[PATCH bpf v2] bpf: fix nested bpf tracepoints with per-cpu data

in nmi context (at most one of which may be a kprobe or perf event). Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data") Signed-off-by: Matt Mullins --- v1->v2: * reverse-Christmas-tree-ize the declarations in bpf_perf_event_output * instantiate err

Re: [PATCH bpf] bpf: fix nested bpf tracepoints with per-cpu data

On Thu, 2019-06-06 at 15:13 -0700, Jakub Kicinski wrote: > On Thu, 6 Jun 2019 11:54:27 -0700, Matt Mullins wrote: > > BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as > > they do not increment bpf_prog_active while executing. > > > > This enab

[PATCH bpf] bpf: fix nested bpf tracepoints with per-cpu data

BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as they do not increment bpf_prog_active while executing. This enables three levels of nesting, to support - a kprobe or raw tp or perf event, - another one of the above that irq context happens to call, and - another one

Re: [PATCH bpf v2] bpf: preallocate a perf_sample_data per event fd

On Tue, 2019-06-04 at 02:43 +0200, Daniel Borkmann wrote: > On 06/04/2019 01:54 AM, Alexei Starovoitov wrote: > > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote: > > > On 06/04/2019 01:27 AM, Alexei Starovoitov wrote: > > > > On Mon, Jun 3, 2019

Re: [PATCH bpf v2] bpf: preallocate a perf_sample_data per event fd

On Mon, 2019-06-03 at 15:22 +0200, Daniel Borkmann wrote: > On 06/03/2019 03:08 PM, Daniel Borkmann wrote: > > On 06/01/2019 12:37 AM, Matt Mullins wrote: > > > It is possible that a BPF program can be called while another BPF > > > program is executing bpf_perf_e

[PATCH bpf v2] bpf: preallocate a perf_sample_data per event fd

t and fail a bpf_perf_event_output if that element is concurrently being used. Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data") Signed-off-by: Matt Mullins --- v1->v2: keep a pointer to the struct perf_sample_data rather than directly embedd

[PATCH] x86/kgdb: return 0 from kgdb_arch_set_breakpoint

. Cannot access memory at address 0x81288910 Command aborted. Fixes: 86a22057127d ("x86/kgdb: Avoid redundant comparison of patched code") Signed-off-by: Matt Mullins --- arch/x86/kernel/kgdb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/

Re: [PATCH bpf] bpf: preallocate a perf_sample_data per event fd

On Thu, 2019-05-30 at 23:28 +, Song Liu wrote: > > On May 30, 2019, at 3:55 PM, Matt Mullins wrote: > > > > It is possible that a BPF program can be called while another BPF > > program is executing bpf_perf_event_output. This has been observed with > > I/O co

[PATCH bpf] bpf: preallocate a perf_sample_data per event fd

t and fail a bpf_perf_event_output if that element is concurrently being used. Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data") Signed-off-by: Matt Mullins --- It felt a bit overkill, but I had to split bpf_event_entry into its own header file to break a

[PATCH bpf-next v3 5/5] selftests: bpf: test writable buffers in raw tps

tracepoint in bpf_prog_test_run Signed-off-by: Matt Mullins --- include/trace/events/bpf_test_run.h | 50 net/bpf/test_run.c| 4 + .../raw_tp_writable_reject_nbd_invalid.c | 40 ++ .../bpf/prog_tests/raw_tp_writable_test_run.c | 80

Re: [PATCH bpf-next v2] bpf: support raw tracepoints in modules

On Thu, 2018-12-13 at 19:22 +, Martin Lau wrote: > On Wed, Dec 12, 2018 at 04:42:37PM -0800, Matt Mullins wrote: > > Distributions build drivers as modules, including network and filesystem > > drivers which export numerous tracepoints. This enables > > bpf(BPF_RAW_TRACE

[PATCH bpf-next v2] bpf: support raw tracepoints in modules

Distributions build drivers as modules, including network and filesystem drivers which export numerous tracepoints. This enables bpf(BPF_RAW_TRACEPOINT_OPEN) to attach to those tracepoints. Signed-off-by: Matt Mullins --- v1->v2: * avoid taking the mutex in bpf_event_notify when op is neit

Re: [PATCH net] tls: don't use stack memory in a scatterlist

On Thu, 2018-05-17 at 14:50 -0400, David Miller wrote: > I'm surprised this problem wasn't discovered sooner. How exactly did you > discover it? Did you actually see it trigger or is this purely from code > inspection? Honestly, I'm not sure how it got uncovered, but it was observed at runtime.

Re: [PATCH net] tls: don't use stack memory in a scatterlist

On Thu, 2018-05-17 at 14:50 -0400, David Miller wrote: > I'm surprised this problem wasn't discovered sooner. How exactly did you > discover it? Did you actually see it trigger or is this purely from code > inspection? Honestly, I'm not sure how it got uncovered, but it was observed at runtime.

[PATCH net] tls: don't use stack memory in a scatterlist

scatterlist code expects virt_to_page() to work, which fails with CONFIG_VMAP_STACK=y. Fixes: c46234ebb4d1e ("tls: RX path for ktls") Signed-off-by: Matt Mullins <mmull...@fb.com> --- include/net/tls.h | 3 +++ net/tls/tls_sw.c | 9 - 2 files changed, 7 insertions

[PATCH net] tls: don't use stack memory in a scatterlist

scatterlist code expects virt_to_page() to work, which fails with CONFIG_VMAP_STACK=y. Fixes: c46234ebb4d1e ("tls: RX path for ktls") Signed-off-by: Matt Mullins --- include/net/tls.h | 3 +++ net/tls/tls_sw.c | 9 - 2 files changed, 7 insertions(+), 5 deletions(-)

Re: [RFC] KVM: SVM: ignore type when setting segment registers

On Tue, May 30, 2017 at 02:54:21PM +0200, Radim Krčmář wrote: > 2017-05-29 15:24+0200, Gioh Kim: > > If so, why type is checked when setting segment registers? > > No idea. 19bca6ab75d8 ("KVM: SVM: Fix cross vendor migration issue with > unusable bit") also moved the assigment up to initialize

Re: [RFC] KVM: SVM: ignore type when setting segment registers

On Tue, May 30, 2017 at 02:54:21PM +0200, Radim Krčmář wrote: > 2017-05-29 15:24+0200, Gioh Kim: > > If so, why type is checked when setting segment registers? > > No idea. 19bca6ab75d8 ("KVM: SVM: Fix cross vendor migration issue with > unusable bit") also moved the assigment up to initialize

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Sat, Feb 04, 2017 at 11:47:38AM +0800, Yisheng Xie wrote: > On 2016/10/18 1:06, Andy Lutomirski wrote: > > hw_random carefully avoids using a stack buffer except in > > add_early_randomness(). This causes a crash in virtio_rng if > > CONFIG_VMAP_STACK=y. > I try to understand this patch, but I

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Sat, Feb 04, 2017 at 11:47:38AM +0800, Yisheng Xie wrote: > On 2016/10/18 1:06, Andy Lutomirski wrote: > > hw_random carefully avoids using a stack buffer except in > > add_early_randomness(). This causes a crash in virtio_rng if > > CONFIG_VMAP_STACK=y. > I try to understand this patch, but I

virtio-rng scatterlist null pointer dereference with VMAP_STACK=y

With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash: [1.470437] BUG: unable to handle kernel NULL pointer dereference at (null) [1.473350] IP: [] sg_init_one+0x65/0x90 [1.474658] PGD 0 [1.475169] Oops: [#1] SMP Entering kdb (current=0x880069b0c980, pid

virtio-rng scatterlist null pointer dereference with VMAP_STACK=y

With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash: [1.470437] BUG: unable to handle kernel NULL pointer dereference at (null) [1.473350] IP: [] sg_init_one+0x65/0x90 [1.474658] PGD 0 [1.475169] Oops: [#1] SMP Entering kdb (current=0x880069b0c980, pid

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

On Tue, Aug 16, 2016 at 12:19:42PM -0700, Yinghai Lu wrote: > On Mon, Aug 15, 2016 at 9:01 PM, Matt Mullins <mmull...@mmlx.us> wrote: > > > > This appears to have a negative effect on booting the Intel Edison > > platform, as > > it uses u-boot as its

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

On Tue, Aug 16, 2016 at 12:19:42PM -0700, Yinghai Lu wrote: > On Mon, Aug 15, 2016 at 9:01 PM, Matt Mullins wrote: > > > > This appears to have a negative effect on booting the Intel Edison > > platform, as > > it uses u-boot as its bootloader. u-boot does not copy t

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

[added Simon Glass to CC in case there's some input from u-boot] On Thu, Apr 28, 2016 at 05:09:04PM -0700, Kees Cook wrote: > From: Yinghai Lu > > This patch adds BP_init_size (which is the INIT_SIZE as passed in from > the boot_params) into asm-offsets.c to make it visible

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

[added Simon Glass to CC in case there's some input from u-boot] On Thu, Apr 28, 2016 at 05:09:04PM -0700, Kees Cook wrote: > From: Yinghai Lu > > This patch adds BP_init_size (which is the INIT_SIZE as passed in from > the boot_params) into asm-offsets.c to make it visible to the assembly >

Re: [PATCH] perf tools: get version from uname(2), not /proc

On Wed, Oct 07, 2015 at 11:19:17AM +0300, Adrian Hunter wrote: > On 07/10/15 11:18, Jiri Olsa wrote: > > On Tue, Oct 06, 2015 at 03:53:14PM -0700, Matt Mullins wrote: > >> Tools in kmod (e.g. modprobe) compose the module path from the release > >> from uname(2).

Re: [PATCH] perf tools: get version from uname(2), not /proc

On Wed, Oct 07, 2015 at 11:19:17AM +0300, Adrian Hunter wrote: > On 07/10/15 11:18, Jiri Olsa wrote: > > On Tue, Oct 06, 2015 at 03:53:14PM -0700, Matt Mullins wrote: > >> Tools in kmod (e.g. modprobe) compose the module path from the release > >> from uname(2).

[PATCH] perf tools: get version from uname(2), not /proc

Tools in kmod (e.g. modprobe) compose the module path from the release from uname(2). Because we use the UNAME26 personality, we need perf to find modules located at the same path as the system tools. Signed-off-by: Matt Mullins Cc: Vinson Lee --- tools/perf/util/machine.c | 28

[PATCH] perf tools: get version from uname(2), not /proc

Tools in kmod (e.g. modprobe) compose the module path from the release from uname(2). Because we use the UNAME26 personality, we need perf to find modules located at the same path as the system tools. Signed-off-by: Matt Mullins <mmull...@twopensource.com> Cc: Vinson Lee <v...@twopens

Re: [PATCH v11 21/21] brd: Rename XIP to DAX

On Thu, Sep 25, 2014 at 04:33:38PM -0400, Matthew Wilcox wrote: > --- a/drivers/block/brd.c > +++ b/drivers/block/brd.c > @@ -97,13 +97,13 @@ static struct page *brd_insert_page(struct brd_device > *brd, sector_t sector) >* Must use NOIO because we don't want to recurse back into the >

Re: [PATCH v11 21/21] brd: Rename XIP to DAX

On Thu, Sep 25, 2014 at 04:33:38PM -0400, Matthew Wilcox wrote: --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -97,13 +97,13 @@ static struct page *brd_insert_page(struct brd_device *brd, sector_t sector) * Must use NOIO because we don't want to recurse back into the *

Re: [PATCH] kernel/sys.c: Fix UNAME26 for 4.0

I'll raise my hand in agreement with Andi -- this is functionality that we do use. Tested-by: Matt Mullins -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH] kernel/sys.c: Fix UNAME26 for 4.0

I'll raise my hand in agreement with Andi -- this is functionality that we do use. Tested-by: Matt Mullins mmull...@twopensource.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [PATCH] perf hist browser: change print format from lu to llu to fit u64 type

On Tue, Nov 18, 2014 at 05:00:27PM -0600, Tom Huynh wrote: > nr_events in tools/perf/ui/browsers/hists.c is of type u64, thus it should > be printed as %llu instead of %lu. The print format %lu causes perf report > to show 0 event count when running with 32-bit userspace without > redirection.

Re: [PATCH] perf hist browser: change print format from lu to llu to fit u64 type

On Tue, Nov 18, 2014 at 05:00:27PM -0600, Tom Huynh wrote: nr_events in tools/perf/ui/browsers/hists.c is of type u64, thus it should be printed as %llu instead of %lu. The print format %lu causes perf report to show 0 event count when running with 32-bit userspace without redirection. This

Re: [PATCH] mm/balloon_compaction: fix deflation when compaction is disabled

k > pages with balloon and doesn't set PagePrivate flag, as a result > balloon_page_dequeue cannot get any pages because it thinks that > all of them are isolated. Without balloon compaction nobody can > isolate ballooned pages, it's safe to remove this check. > > Signed-off-by: Konstantin

Re: [PATCH] mm/balloon_compaction: fix deflation when compaction is disabled

-by: Matt Mullins mmull...@mmlx.us Cc: Stable sta...@vger.kernel.org (v3.17) That seems to do it, thanks! Tested-by: Matt Mullins mmull...@mmlx.us -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [PATCH v3 1/4] mm/balloon_compaction: redesign ballooned pages management

On Tue, Oct 28, 2014 at 11:56:15PM +0400, Konstantin Khlebnikov wrote: > On Tue, Oct 28, 2014 at 9:47 PM, Matt Mullins wrote: > > On Sat, Sep 27, 2014 at 11:15:16PM +0400, Konstantin Khlebnikov wrote: > >> This patch fixes all of them. > > > > It seems to have rend

Re: [PATCH v3 1/4] mm/balloon_compaction: redesign ballooned pages management

On Sat, Sep 27, 2014 at 11:15:16PM +0400, Konstantin Khlebnikov wrote: > This patch fixes all of them. It seems to have rendered virtio_balloon completely ineffective without CONFIG_COMPACTION and CONFIG_BALLOON_COMPACTION, even for the case that I'm expanding the memory available to my VM. Was

Re: [PATCH v3 1/4] mm/balloon_compaction: redesign ballooned pages management

On Sat, Sep 27, 2014 at 11:15:16PM +0400, Konstantin Khlebnikov wrote: This patch fixes all of them. It seems to have rendered virtio_balloon completely ineffective without CONFIG_COMPACTION and CONFIG_BALLOON_COMPACTION, even for the case that I'm expanding the memory available to my VM. Was

Re: [PATCH v3 1/4] mm/balloon_compaction: redesign ballooned pages management

On Tue, Oct 28, 2014 at 11:56:15PM +0400, Konstantin Khlebnikov wrote: On Tue, Oct 28, 2014 at 9:47 PM, Matt Mullins mmull...@mmlx.us wrote: On Sat, Sep 27, 2014 at 11:15:16PM +0400, Konstantin Khlebnikov wrote: This patch fixes all of them. It seems to have rendered virtio_balloon

Re: [PATCH v2] nfs: fix kernel warning when removing proc entry

pushed toward Linus: Tested-by: Matt Mullins -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v2] nfs: fix kernel warning when removing proc entry

toward Linus: Tested-by: Matt Mullins mmull...@twopensource.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: Problems with hda_intel, Santa Rosa, and suspend

development; thankfully, Intel has good documentation. I'm going to keep hacking to see what information I can figure out. I just tried 2.6.22-rc5, and no behavior has changed. Matt Mullins On 6/17/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: On Sunday, 17 June 2007 03:36, Matt M

Re: Problems with hda_intel, Santa Rosa, and suspend

development; thankfully, Intel has good documentation. I'm going to keep hacking to see what information I can figure out. I just tried 2.6.22-rc5, and no behavior has changed. Matt Mullins On 6/17/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Sunday, 17 June 2007 03:36, Matt Mullins

Problems with hda_intel, Santa Rosa, and suspend

the second set (when something tries to use the card) that last word is 0x0650 or 0x0011. I have yet to go back and re-test compiling snd-hda-intel as a module. Thank you in advance, Matt Mullins - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a mes

Problems with hda_intel, Santa Rosa, and suspend

to use the card) that last word is 0x0650 or 0x0011. I have yet to go back and re-test compiling snd-hda-intel as a module. Thank you in advance, Matt Mullins - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info