Re: [PATCH 6/7] lib/bitmap.c: fix remaining space computation in bitmap_print_to_pagebuf
From: Andy Shevchenko
Date: Sun Aug 19 2018 - 08:37:56 EST
On Sat, Aug 18, 2018 at 4:17 PM Rasmus Villemoes
> For various alignments of buf, the current expression computes
> 4096 ok
> 4095 ok
> i.e., if the caller has already written two bytes into the page buffer,
> len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next
> boundary. So if the printed version of the bitmap is huge, scnprintf()
> ends up writing beyond the page boundary.
> I don't think any current callers actually write anything before
> bitmap_print_to_pagebuf, but the API seems to be designed to allow it.
> Signed-off-by: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
> lib/bitmap.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 1f73b2e52186..277c9a63a5ab 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -460,14 +460,15 @@ EXPORT_SYMBOL(bitmap_parse_user);
> * ranges if list is specified or hex digits grouped into comma-separated
> * sets of 8 digits/set. Returns the number of characters written to buf.
> - * It is assumed that @buf is a pointer into a PAGE_SIZE area and that
> - * sufficient storage remains at @buf to accommodate the
> - * bitmap_print_to_pagebuf() output.
> + * It is assumed that @buf is a pointer into a PAGE_SIZE, page-aligned
> + * area and that sufficient storage remains at @buf to accommodate the
> + * bitmap_print_to_pagebuf() output. Returns the number of characters
> + * actually printed to @buf, excluding terminating '\0'.
> int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
> int nmaskbits)
> - ptrdiff_t len = PTR_ALIGN(buf + PAGE_SIZE - 1, PAGE_SIZE) - buf;
> + ptrdiff_t len = PAGE_SIZE - ((unsigned long)buf & (PAGE_SIZE-1));
Don't we have offset_in_page() helper macro?
With Best Regards,