linux-kernel - Re: [PATCH v2] lib/test_bpf: Call page_address() on page acquired with GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230622051306.GA422371@sumitra.com>
Date:   Wed, 21 Jun 2023 22:13:06 -0700
From:   Sumitra Sharma <sumitraartsy@...il.com>
To:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
        Ira Weiny <ira.weiny@...el.com>,
        Deepak R Varma <drv@...lo.com>,
        Sumitra Sharma <sumitraartsy@...il.com>
Subject: Re: [PATCH v2] lib/test_bpf: Call page_address() on page acquired
 with GFP_KERNEL flag

On Sun, Jun 18, 2023 at 07:07:00AM +0200, Fabio M. De Francesco wrote:
> On martedì 13 giugno 2023 09:17:56 CEST Sumitra Sharma wrote:
> > generate_test_data() acquires a page with alloc_page(GFP_KERNEL). Pages
> > allocated with GFP_KERNEL cannot come from Highmem. This is why
> > there is no need to call kmap() on them.
> > 
> > Therefore, use a plain page_address() on that page.
> > 
> > Suggested-by: Fabio M. De Francesco <fmdefrancesco@...il.com>
> > Signed-off-by: Sumitra Sharma <sumitraartsy@...il.com>
> > ---
> > 
> > Changes in v2:
> > 	- Remove the kmap() call and call page_address() instead.
> 
> NIT: Give credit to whom asked you for this removal and explain why the 
> mapping is not required.

> 
> > 	- Change the commit subject and message.
> > 
> >  lib/test_bpf.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> > index ade9ac672adb..70fcd0bcf14b 100644
> > --- a/lib/test_bpf.c
> > +++ b/lib/test_bpf.c
> > @@ -14388,11 +14388,10 @@ static void *generate_test_data(struct bpf_test
> > *test, int sub) if (!page)
> >  			goto err_kfree_skb;
> > 
> > -		ptr = kmap(page);
> > +		ptr = page_address(page);
> >  		if (!ptr)
> >  			goto err_free_page;
> 
> What is the reason of this test? Could "ptr" ever be NULL? What is the code 
> checking just few lines above this latter test?
> 


The code is allocating a page using alloc_page() with the GFP_KERNEL flag to 
obtain a kernel page frame. The checks if (!page) and if (!ptr) are verifying 
if the page allocation or the mapping operation were successful. 

If the pages obtained through page_address() are not from the highmem zone, 
the page_address() function will always return a valid kernel virtual address 
and will not return NULL. Hence, the check !ptr can be ignored while the !page
must remain.

I will be working on the v2 patch.

I will also add the credits and add new lines to commit message
explaining why the mapping is not required.

Thank you for the help.

Thanks & regards
Sumitra

> Please, take a deeper look at this function as a whole.
> 
> Fabio
> 
> >  		memcpy(ptr, test->frag_data, MAX_DATA);
> > -		kunmap(page);
> >  		skb_add_rx_frag(skb, 0, page, 0, MAX_DATA, MAX_DATA);
> >  	}
> > 
> > --
> > 2.25.1
> 
> 
> 
>