Cc: Martin 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: syzbo
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) her
...@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_pro
> 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:
> >
> > com
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
_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")
Si
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:
> > >
> > > kernel/trace/bpf_trace.c:
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
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
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
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
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
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
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
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
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
.
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/
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
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
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
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
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
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.
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(-)
di
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 it
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
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 1
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
[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
> cod
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).
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
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
>
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.kerne
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. Thi
t; 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:
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
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 t
t it 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/
done any kernel 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 Jun
r 0x0009. For 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
th
40 matches
Mail list logo