All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lstoakes@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	urezki@gmail.com, stephen.s.brennan@oracle.com,
	willy@infradead.org, akpm@linux-foundation.org,
	hch@infradead.org
Subject: Re: [PATCH v2 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas
Date: Mon, 9 Jan 2023 07:12:53 +0000	[thread overview]
Message-ID: <Y7u+dQfq3ZbDcf/d@lucifer> (raw)
In-Reply-To: <Y7uZeBj56VcnJhzJ@fedora>

On Mon, Jan 09, 2023 at 12:35:04PM +0800, Baoquan He wrote:
> Sorry for late reply, just come back from vacation.

Hope you had a great time! :)

>
> Lei + mutt sounds like a good idea. I relied too much on mbsync in the
> past.
>

Yeah I'm finding it works well,
https://josefbacik.github.io/kernel/2021/10/18/lei-and-b4.html is a handy guide!

[snip]
> > Maybe let me rephrase:-
> >
> > - We want to read `count` bytes from `addr` into `buf`
> > - We iterate over _used_ blocks, placing the start/end of each block in `rs`, `re`
> >   respectively.
> > - If we hit a block whose start address is above the one in which we are interested then:-
> >   - Place a zero byte in the buffer
> >   - Increment `addr` by 1 byte
> >   - Decrement the `count` by 1 byte
> >   - Carry on
> >
> > I am seriously confused as to why we do this? Surely we should be checking
> > whether the range [addr, addr + count) overlaps this block at all, and only then
> > copying the relevant region?
>
> I guessed this could be your concern, but not very sure. That
> code block is copied from vread(), and my considerations are:
> 1) We could starting read from any position of kcore file. /proc/kcore
> is a elf file logically, it's allowed to read from anywhere, right? We
> don't have to read the entire file always. So the vmap_block reading is
> not necessarily page aligned. It's very similar with the empty area
> filling in vread().
> 2) memset() is doing the byte by byte reading. We can
> change code as below. While we don't save the effort very much, and we
> need introduce an extra local variable to store the value of
> (start - end).
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index b054081aa66b..dce4a843a9e8 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3576,6 +3576,15 @@ static void vmap_ram_vread(char *buf, char *addr, int count, unsigned long flags
> +		if (addr < start) {
> +			int num = min(count, (start - add));
> +			memset(buf, 0, count);
> +			count -= num;
> +			if (count == 0)
> +				break;
> +			buf -= num;
> +			addr -= num;
> +		}
>  		/*it could start reading from the middle of used region*/
>  		offset = offset_in_page(addr);
>  		n = ((re - rs + 1) << PAGE_SHIFT) - offset;
>

The difference with vread() is that uses a while loop rather than an if clause
so operates over the whole region byte-by-byte, your original would only do this
for 1 byte so now things make a lot more sense!

This approach makes sense though I'd put the count == 0 check first and nit
'add' should be 'addr'.

I am happy with either this or a while loop instead of an if which it seems is
what the original issue was!

> void *memset(void *s, int c, size_t count)
> {
>         char *xs = s;
>
>         while (count--)
>                 *xs++ = c;
>         return s;
> }
>
> >
> > It's the fact that blocks are at base page granularity but then this condition
> > is at byte granularity that is confusing to me (again it's _very_ possible I am
> > just being dumb here and missing something, just really want to understand this
> > better :)
>
> I like this kind of reviewing with careful checking and deep thinking.
> For above code block, I think it's a very great point. From my point of
> view, I like the memset version better, it's easier to understand. If we
> all agree, we can change it to take memset way. When I made patches,
> several issues related to patches were hovering in my mind at the same
> time, I did not consider this one so deeply.
>

Thanks :) I have a particular interest in vmalloc so am happy to dive in with
reviews here!

> >
> > > > > -		vm = va->vm;
> > > > > -		vaddr = (char *) vm->addr;
> > > > > -		if (addr >= vaddr + get_vm_area_size(vm))
> > > > > +		vaddr = (char *) va->va_start;
> > > > > +		size = flags ? va_size(va) : get_vm_area_size(vm);
> > > >
> > > > For example here, I feel that this ternary should be reversed and based on
> > > > whether vm is null, unles we expect vm to ever be non-null _and_ flags to be
> > > > set?
> > >
> > > Now only vm_map_ram area sets flags, all other types has vm not null.
> > > Since those temporary state, e.g vm==NULL, flags==0 case has been
> > > filtered out. Is below you suggested?
> > >
> > > 		size = (!vm&&flags)? va_size(va) : get_vm_area_size(vm);
> > > 		or
> > > 		size = (vm&&!flags)? get_vm_area_size(vm):va_size(va);
> > >
> >
> > Sorry I didn't phrase this very well, my point is that the key thing you're
> > relying on here is whether vm exists in order to use it so I simply meant:-
> >
> > size = vm ? get_vm_area_size(vm) : va_size(va);
> >
> > This just makes it really explicit that you need vm to be non-NULL, and you've
> > already done the flags check before so this should suffice.
>
> Sounds reasonable, I will copy above line you pasted. Thanks a lot.
>

Cheers!


  reply	other threads:[~2023-01-09  7:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-17  1:54 [PATCH v2 0/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Baoquan He
2022-12-17  1:54 ` [PATCH v2 1/7] mm/vmalloc.c: add used_map into vmap_block to track space of vmap_block Baoquan He
2022-12-17  1:54 ` [PATCH v2 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area Baoquan He
2022-12-17 11:44   ` Lorenzo Stoakes
2022-12-19  8:01     ` Baoquan He
2022-12-19  9:09       ` Lorenzo Stoakes
2022-12-19 12:24         ` Baoquan He
2022-12-19 13:01           ` Lorenzo Stoakes
2022-12-20 12:14             ` Baoquan He
2022-12-20 12:42               ` Lorenzo Stoakes
2022-12-20 16:55   ` Uladzislau Rezki
2022-12-23  4:14     ` Baoquan He
2023-01-13  3:55       ` Baoquan He
2023-01-16 17:54         ` Uladzislau Rezki
2023-01-18  3:09           ` Baoquan He
2023-01-18 12:20             ` Uladzislau Rezki
2022-12-17  1:54 ` [PATCH v2 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Baoquan He
2022-12-17  4:10   ` kernel test robot
2022-12-17  6:41   ` kernel test robot
2022-12-17  9:46     ` Baoquan He
2022-12-17 12:06   ` Lorenzo Stoakes
2023-01-04  8:01     ` Baoquan He
2023-01-04 20:20       ` Lorenzo Stoakes
2023-01-09  4:35         ` Baoquan He
2023-01-09  7:12           ` Lorenzo Stoakes [this message]
2023-01-09 12:49             ` Baoquan He
2022-12-17  1:54 ` [PATCH v2 4/7] mm/vmalloc: explicitly identify vm_map_ram area when shown in /proc/vmcoreinfo Baoquan He
2022-12-17  1:54 ` [PATCH v2 5/7] mm/vmalloc: skip the uninitilized vmalloc areas Baoquan He
2022-12-17 12:07   ` Lorenzo Stoakes
2022-12-19  7:16     ` Baoquan He
2022-12-17  1:54 ` [PATCH v2 6/7] powerpc: mm: add VM_IOREMAP flag to the vmalloc area Baoquan He
2022-12-17  1:54   ` Baoquan He
2022-12-17  1:54 ` [PATCH v2 7/7] sh: mm: set " Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7u+dQfq3ZbDcf/d@lucifer \
    --to=lstoakes@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stephen.s.brennan@oracle.com \
    --cc=urezki@gmail.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.