* [PATCH bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
@ 2022-01-31 11:46 Hou Tao
2022-01-31 16:28 ` Daniel Borkmann
0 siblings, 1 reply; 4+ messages in thread
From: Hou Tao @ 2022-01-31 11:46 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Martin KaFai Lau, Yonghong Song,
Andrii Nakryiko, David S . Miller, Jakub Kicinski,
John Fastabend, netdev, bpf, houtao1
Now the ringbuf area in /proc/vmallocinfo is showed as vmalloc,
but VM_ALLOC is only used for vmalloc(), and for the ringbuf area
it is created by mapping allocated pages, so use VM_MAP instead.
After the change, ringbuf info in /proc/vmallocinfo will changed from:
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
to
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Signed-off-by: Hou Tao <houtao1@huawei.com>
---
kernel/bpf/ringbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
index 638d7fd7b375..710ba9de12ce 100644
--- a/kernel/bpf/ringbuf.c
+++ b/kernel/bpf/ringbuf.c
@@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
}
rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
- VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
+ VM_MAP | VM_USERMAP, PAGE_KERNEL);
if (rb) {
kmemleak_not_leak(pages);
rb->pages = pages;
--
2.20.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-01-31 11:46 [PATCH bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf Hou Tao
@ 2022-01-31 16:28 ` Daniel Borkmann
2022-02-01 2:25 ` htbegin
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Borkmann @ 2022-01-31 16:28 UTC (permalink / raw)
To: Hou Tao
Cc: Alexei Starovoitov, Martin KaFai Lau, Yonghong Song,
Andrii Nakryiko, David S . Miller, Jakub Kicinski,
John Fastabend, netdev, bpf, houtao1
On 1/31/22 12:46 PM, Hou Tao wrote:
> Now the ringbuf area in /proc/vmallocinfo is showed as vmalloc,
> but VM_ALLOC is only used for vmalloc(), and for the ringbuf area
> it is created by mapping allocated pages, so use VM_MAP instead.
>
> After the change, ringbuf info in /proc/vmallocinfo will changed from:
> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
> to
> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Could you elaborate in the commit msg if this also has some other internal
effect aside from the /proc/vmallocinfo listing? Thanks!
> Signed-off-by: Hou Tao <houtao1@huawei.com>
> ---
> kernel/bpf/ringbuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> index 638d7fd7b375..710ba9de12ce 100644
> --- a/kernel/bpf/ringbuf.c
> +++ b/kernel/bpf/ringbuf.c
> @@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
> }
>
> rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
> - VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
> + VM_MAP | VM_USERMAP, PAGE_KERNEL);
> if (rb) {
> kmemleak_not_leak(pages);
> rb->pages = pages;
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-01-31 16:28 ` Daniel Borkmann
@ 2022-02-01 2:25 ` htbegin
2022-02-02 5:43 ` htbegin
0 siblings, 1 reply; 4+ messages in thread
From: htbegin @ 2022-02-01 2:25 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Martin KaFai Lau, Yonghong Song,
Andrii Nakryiko, David S . Miller, Jakub Kicinski,
John Fastabend, netdev, bpf, Hou Tao
Hi,
On Tue, Feb 1, 2022 at 12:28 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 1/31/22 12:46 PM, Hou Tao wrote:
> > Now the ringbuf area in /proc/vmallocinfo is showed as vmalloc,
> > but VM_ALLOC is only used for vmalloc(), and for the ringbuf area
> > it is created by mapping allocated pages, so use VM_MAP instead.
> >
> > After the change, ringbuf info in /proc/vmallocinfo will changed from:
> > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
> > to
> > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
>
> Could you elaborate in the commit msg if this also has some other internal
> effect aside from the /proc/vmallocinfo listing? Thanks!
>
For now, the VM_MAP flag only affects the output in /proc/vmallocinfo.
Thanks,
Tao
> > Signed-off-by: Hou Tao <houtao1@huawei.com>
> > ---
> > kernel/bpf/ringbuf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> > index 638d7fd7b375..710ba9de12ce 100644
> > --- a/kernel/bpf/ringbuf.c
> > +++ b/kernel/bpf/ringbuf.c
> > @@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
> > }
> >
> > rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
> > - VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
> > + VM_MAP | VM_USERMAP, PAGE_KERNEL);
> > if (rb) {
> > kmemleak_not_leak(pages);
> > rb->pages = pages;
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf
2022-02-01 2:25 ` htbegin
@ 2022-02-02 5:43 ` htbegin
0 siblings, 0 replies; 4+ messages in thread
From: htbegin @ 2022-02-02 5:43 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Martin KaFai Lau, Yonghong Song,
Andrii Nakryiko, David S . Miller, Jakub Kicinski,
John Fastabend, netdev, bpf, Hou Tao
Hi,
On Tue, Feb 1, 2022 at 10:25 AM htbegin <hotforest@gmail.com> wrote:
>
> Hi,
>
> On Tue, Feb 1, 2022 at 12:28 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 1/31/22 12:46 PM, Hou Tao wrote:
> > > Now the ringbuf area in /proc/vmallocinfo is showed as vmalloc,
> > > but VM_ALLOC is only used for vmalloc(), and for the ringbuf area
> > > it is created by mapping allocated pages, so use VM_MAP instead.
> > >
> > > After the change, ringbuf info in /proc/vmallocinfo will changed from:
> > > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
> > > to
> > > [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
> >
> > Could you elaborate in the commit msg if this also has some other internal
> > effect aside from the /proc/vmallocinfo listing? Thanks!
> >
> For now, the VM_MAP flag only affects the output in /proc/vmallocinfo.
Just find out that the VM_ALLOC will be used to check whether or not
the mapped area needs to be marked as accessible by commit
2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping").
And the patch can fix the vmalloc oob access reported by syzbot [1] ,
I will post v2
to illustrate that.
Regards,
Tao
[1]: https://lore.kernel.org/bpf/0000000000000a9b7d05d6ee565f@google.com/T/#u
>
> Thanks,
> Tao
> > > Signed-off-by: Hou Tao <houtao1@huawei.com>
> > > ---
> > > kernel/bpf/ringbuf.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> > > index 638d7fd7b375..710ba9de12ce 100644
> > > --- a/kernel/bpf/ringbuf.c
> > > +++ b/kernel/bpf/ringbuf.c
> > > @@ -104,7 +104,7 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(size_t data_sz, int numa_node)
> > > }
> > >
> > > rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages,
> > > - VM_ALLOC | VM_USERMAP, PAGE_KERNEL);
> > > + VM_MAP | VM_USERMAP, PAGE_KERNEL);
> > > if (rb) {
> > > kmemleak_not_leak(pages);
> > > rb->pages = pages;
> > >
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-02-02 5:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-31 11:46 [PATCH bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf Hou Tao
2022-01-31 16:28 ` Daniel Borkmann
2022-02-01 2:25 ` htbegin
2022-02-02 5:43 ` htbegin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.