diff mbox series

[bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf

Message ID 20220131114600.21849-1-houtao1@huawei.com (mailing list archive)
State Superseded
Delegated to: BPF
Headers show
Series [bpf-next] bpf: use VM_MAP instead of VM_ALLOC for ringbuf | expand

Checks

Context Check Description
bpf/vmtest-bpf-next success VM_Test
bpf/vmtest-bpf-next-PR success PR summary
netdev/tree_selection success Clearly marked for bpf-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix success Link
netdev/cover_letter success Single patches do not need cover letters
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 2 this patch: 2
netdev/cc_maintainers warning 2 maintainers not CCed: kpsingh@kernel.org songliubraving@fb.com
netdev/build_clang success Errors and warnings before: 20 this patch: 20
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 7 this patch: 7
netdev/checkpatch warning WARNING: From:/Signed-off-by: email address mismatch: 'From: Hou Tao <hotforest@gmail.com>' != 'Signed-off-by: Hou Tao <houtao1@huawei.com>'
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Hou Tao Jan. 31, 2022, 11:46 a.m. UTC
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(-)

Comments

Daniel Borkmann Jan. 31, 2022, 4:28 p.m. UTC | #1
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;
>
Hou Tao Feb. 1, 2022, 2:25 a.m. UTC | #2
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;
> >
>
Hou Tao Feb. 2, 2022, 5:43 a.m. UTC | #3
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;
> > >
> >
diff mbox series

Patch

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;